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I. INTRODUCTION 


This chapter provides introductory information on the purpose and content of the 
thesis. It discusses the background and objectives of the research, the research questions 
and methodology used. It defines the scope of the thesis, and provides a list of acronyms 
used throughout. Finally, it outlines the content of each of the chapters. 


A. BACKGROUND 


The Marine Corps Institute (MCI) was established to "develop, publish, distribute, 
and administer distance training and education materials to enhance, support, or develop 
required skills and knowledge of Marines and to satisfy other training and education 
requirements as identified by the Commanding General, MCCDC" (MCI Mission, 1997). 
To accomplish its mission, MCI is organized into seven functional departments: education 
and operations, student services, information management systems, occupation specialty, 
professional military education, production, and logistics. 

The mission of the student services department is to support the enrollment, 
grading and management of the Marine Corps distance education and training programs. 
In support of its mission, the student services department employs an automated 
information system (AIS) to automate the actions required to support a student in the 
MCI correspondence program, maintain student records, and produce necessary 
management reports. The automated system, known as the Marine Corps Institute 
Automated Informat .n System (MCIAIS), is a legacy system developed in the late 
1970's. It runs on a Hewlett-Packard 3000 mini computer running the MPE/iX operating 


system. MCIAIS is v sitten in HP proprietary language "Transact" and accesses a Turbo- 


IMAGE hierarchical database. As is typical of many legacy systems, MCIAIS suffers from 
many shortcomings: 


e Ithas over 110 "spaghetti coded" programs that are difficult to maintain, 
modify, and upgrade. 


e It does not have underlying data or process models. 


e The programs have poor functionality, no statistical analysis capability, and 
limited "ad hoc" query capability. 


e Itutilizes a "closed" non-relational database. 

e It does nci support Graphical User Interfaces (GUI). 

In response to these shortcomings, MCI initiated a modernization project to 
redesign MCIAIS using "open" system architecture (both hardware and software). In 
addition, MCI is also reviewing and redesigning the business processes to better support 
its mission and current advances in training and education. MCI contracted with the Naval 
Postgraduate School to perform an analysis and develop a business process reengineering 
evaluation and migration plan proposal. A team of students was selected by Dr. Magdi N. 
Kamel, Ph.D. to conduct the evaluation and prepare the proposal. 

This thesis documents the process redesign portion of the Student Services 
Department (SSD) intormation system. The research was conducted from August 1996 
through August 1997 The complete project report is available as the following two 
technical reports. 

« NPS-SM-97-001: Analysis, Design, and Prototype Implementation of a 


Contemporary Information System for the Marine Corps Institute, 
Preliminary Report (Kamel et al., 1997) 


° NPS-SM-97-006: Analysis, Design, and Prototype Implementation of a 
Contemporary Information System for the Marine Corps Institute, Final 
Report (Kamel et al., 1997) 


Other Naval Postgraa:ate School theses that cover related aspects of the modernization 
project include: 
e Data model design: A Relational Database Model and Data Migration 


Plan for the Student Services Department at the Marine Corps Institute 
(Slaughter, 1997). 


° Architecture model design: A System Architecture and Migration Plan 
for the Student Services Department of the Marine Corps Institute (Evers 
c., 1997): 

€ Prototype design: Development of Graphical User Interface Standards 


and Prototype for the Student Services Department of the Marine Corps 
Institute (Hehe, 1997). 


B. OBJECTIVE 

The objective  f this thesis is to perform a detailed analysis of process 
requirements, review existing processes, develop the AS IS process model, redesign the 
processes to increase efficiency and reduce costs, and develop a TO BE process model to 
improve the current business processes using IDEFO models. Additionally, data flow 
diagrams of the To-Be AIS were developed to assist in prototype design and coding. 
C. RESEARCH QUESTIONS 

This research was focused on the following questions: 


e Can a process model be developed to reflect the current business process of 
the Studet't Services Department of the Marine Corps Institute (MCI)? 


e Can the business process of the Student Services Department of MCI be 
reengineered? 


e Can a process model be developed to reflect the reengineered business process 
of the Student Services Department of MCI? 


e What BPR methodology is most suitable for reengineering the Student 
Services Department of MCI? 


e What CASE tool is most suitable for reengineering the Student Services 
Department of MCI? 


e Cana CRUD diagram be developed to support the BPR of the Student 
Services Department of MCI? 


D. SCOPE, LIMITATIONS, ASSUMPTIONS 


Prior to reengineering a large and complex organization, a business process 
reengineering methodology, a modeling technique, and supporting CASE tools must be 
identified. Once these are chosen, reengineering begins at the enterprise level and 
progresses down through the organization examining every process for ways to improve 
it. This thesis focuses on the process modeling, analysis, and redesign of the Student 
Services Department of the Marine Corps Institute. Other business areas at MCI identified 
in the enterprise analysis could be analyzed in a similar fashion in future efforts. 


E. RESEARCH METHODOLOGY 

Following a literature survey of business process reengineering methodologies, the 
methodology adopted for this research combines classic business process reengineering 
philosophy with information engineering techniques developed by James Martin. Before 
the data gathering stage of the project, considerable time was spent by the authors 
evaluating potential CASE tools. Once a CASE tool was chosen, more time was spent 
developing expertise with the tool’s features and capabilities. With the technical ground 
work laid, the authors each made three trips to MCI to interview personnel, observe daily 


operations, and gather documents. Personal visits were augmented by telephone 


conversations and the electronic exchange of model diagrams and associated information. 


The information gathered was analyzed and structured by conducting the following 
activities: MCI enterprise analysis, business area analysis of the Student Services 
Department resulting in As-Is model development, logical redesign of the Student Services 
Department processes, To-Be model development, and SSD information system model 
redesign. The final result was a proof-of-concept prototype fully described in another team 
member’s thesis (Hehe, 1997). Complete model diagrams and documentation are 
contained in Naval Postgraduate School Technical Reports cited earlier. 


F. DEFINITIONS AND ABBREVIATIONS 


The following definitions and abbreviations are used throughout the thesis. 


ABC Activity Based Costing 
AIS Automated Information System 


ALMAR All Marine Message 


AVRS Automated Voice Response System 
BAA Business Area Analysis 

BPI Business Process Improvement 

BPR Business Process Reengineering 
CASE Computer Aided System Engineering 
CIM Corporate Information Management 
DoD Department of Defense 

FEA Functional Economic Analysis 

FPI Functional Process Improvement 
GUI Graphical User Interface 


HQMC 


ICOM 


HD BU 


IT 
LOGAIS 
MCC 
MCCDC 
MCI 
MCIAIS 
MCTFS 
MCU 
MIS 
MISD 
MOS 
NCO 
OSD 
PME 
PMED 
RUC 
SNCO 


SSD 


Headquarters, United States Marine Corps 


Input, Control, Output, Mechanism (acronym for all arrows on an 
IDEFO activity model) 


Integrated Definition for Information 
Modeling Language for Process Modeling 


Information Technology 

Logistics Automated Information System 

Major Command Code 

Marine Corps Combat Development Command 
Marine Corps Institute 

Marine Corps Institute Automated Information System 
Marine Corps Total Force System 

Marine Corps University 

Management of Information Systems 
Management of Information Systems Department 
Military Occupational Specialty 
Noncommissioned Officer 

Occupational Specialty Department 

Professional Military Education 

Professional Military Education Department 
Reporting Unit Code 

Staff Noncommissioned Officer 


Student Services Department 


SSN Social Security Number 
UAR Unit Activity Report 
USMC United States Marine Corps 


G. ORGANIZATION OF STUDY 


Chapter II of this thesis is a description of the Marine Corps Institute, the 
problems with its current information system, and the overarching MCI modernization 
project. Chapter III discusses the information engineering methodology developed by 
James Martin and how it was applied to the MCI modernization project. Chapter IV 
discusses business process reengineering methodology and its application to reengineering 
the Student Services Department of MCI. Chapter V is a discussion of the IDEFO 
modeling technique, f:nctional decomposition techniques, data flow diagramming, and 
CASE tool alternatives that were considered for use on this project. Chapter VI presents 
the enterprise analysis of MCI. Chapter VII details the business area analysis and the 
information system design portions of the methodology to the Student Services 
Department of MCI. Finally, Chapter VIII details recommendations for implementation 


and further research, and conclusions. 





Ii. THE MCI MODERNIZATION PROJECT 


This chapter provides the details of the Marine Corps Institute (MCI) 
Modernization Project performed by the Naval Postgraduate School MCI Thesis Team. 
The chapter begins with a background of MCI, which includes a discussion of its history, 
mission, organizatior. and description. The chapter introduces the MCI Automated 
Information System (MCIAIS) identifying the system interfaces, non-system interfaces, 
and known problems. The chapter presents the strategic plan for the enterprise-wide 
modernization effort of MCI. It then discusses the Naval Postgraduate School (NPS) role, 
the NPS MC] team members and their focused area of research. The chapter concludes 
with the benefits that MCI will reap from the project presented in a “process perspective”’. 


A. MCI BACKGROUND 


MCI started as a school house 1n Quantico with part-time Marine instructors, but 
quickly developed into an accredited correspondence school. It was established to provide 
vocational training and personal development through part-time education during a period 
of the 1920s fraught vith military indifference. A bnef review of its history, mission, 
organization and descnption of services may shed some light on where its future should 
lead. (MCI Dream, 1997) 


1. History 


Lieutenant General John A. Lejeune is often referred to as “the greatest of all 
Leathernecks.” Among his noteworthy achievements during more than 40 years of service 
include the thirteenth Commandant of the Marine Corps, the first Marine to command an 


Army Division, a recognized strategist and effective leader (Lejeune, 1949). Lejeune also 


established the Fleet larine Force, formalized Amphibious Doctrine (Hough et al., 1997), 
and founded the Marine Corps Institute (MCI Dream, 1997). Lejeune left an indelible 
mark on the Marine Corps challenging leaders to develop their subordinates much like 
“fathers to sons or teachers to scholars’(Larson, 1996). 

Exhibiting thai leadership against substantial resistance, then Major General 
Lejeune issued a Post Order on November 12, 1919, one month after assuming command 
of Marine Barracks Quantico, Virginia, establishing the first three vocational schools in 
the Marine Corps. The schools operated under the premise that normal military duties 
would be performed in the morning and vocational training would be available in the 
afternoon on a voluniery basis. The Vocational Training Schools Detachment at Quantico 
opened on January 5, i920. Courses like Automobile Mechanics, Band Music and Playing, 
Blacksmithing, Carpentry, Cooking and Baking, Drafting, Electrical Mechanics, Forestry, 
Gas Engine Design and Operations, Livestock, Painting, Plumbing, and Stenography and 
Clerical Work clearly demonstrated their utility during that era. (MCI Dream, 1997) 

MCI’s affiliation with correspondence courses began almost as soon as the 
Vocational Training Schools Detachment was established. The first Director, Diener 
Colonel William C. "Bo" Harllee, traveled to Scranton, Pennsylvania and made an 
agreement with International Correspondence School (ICS) to use their courses for the 
instruction of Marine students. ICS reviewed ten percent of the completed examinations 
and Marine officer ins4ructors reviewed the rest. This arrangement provided Marines, that 
satisfactorily completed a course, a completion certificate from ICS and co-signed by the 


Commandant of the Marine Corps. (MCI Dream, 1997) This accreditation and 
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certification philosopt y remains with MCI today, as an incentive and reward for Marines 
pursuing self-improvement. 

The correspondence course aspect was first implemented in May 1920 when 
enrolled students at Quantico were transferred to the USS HENDERSON and ordered to 
counter a potential uprising in Mexico. Lieutenant Colonel Harllee sent a school 
representative with course materials to the ship. The action demonstrated the need, and 
intent, to support Marine education using methods that do not infringe upon the Marine 
warfighting mission “in every clime and place.” The popularity of self-improvement was 
reflected in increased enrollments and a recruiting campaign that offered enlistees an 
assignment to Quanti) where they could enroll in one of the schools. (MCI Dream, 1997) 

MCI has been moved and redesignated many times over the last 77 years. The 
Vocational Training Schools Detachment was forced to close the first month it opened 
because of an influenza epidemic. However, it reopened on the recognized founding date, 
February 2, 1920. The Vocational Training Schools Detachment at Quantico was officially 
designated as the Marine Corps Institute in July of 1920 and moved to Marine Barracks 
Washington, DC on November 10, 1920. In January 1926, military subjects were added to 
the available correspondence courses. In December of 1946, it was organized under the 
Extension Division, Marine Corps Schools. In November of 1953, MCI was directed to 
discontinue its vocatienal courses, which were provided by the U.S. Armed Forces 
Institute, and focus on’y on military subjects. At this time, the arrangements with ICS 
ended. In June of 1977, the National Home Study Council gave accreditation to MCI. In 


October of 1980, the Extension School and MCI was consolidated and all Marine Corps 
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training and education correspondence courses became and the responsibility of the 
Director, Marine Corps Institute. MCI moved to its current location at the Washington 
Navy Yard in November 1993. Today, most MCI courses receive college credit through 


American Council on Education (ACE) accreditation. (MCI History, 1997) 


2. Mission 

MCI has two missions that govern their operations: education of Marines and 
ceremonial support to the Commandant of the Marine Corps. Early in its history, MCI 
administered and distributed correspondence courses developed by ICS. Today, in 
addition to administration and distribution, MCI must also identify and develop the 
courses that improve Marine proficiency. This shift in focus accounts for the evolution to 
MCI’s current mission (MCI In-Brief, 1996): 

To develop, publish, distribute, and administer distance training and education 

materials to enhance, support, or develop required skills and knowledge of 


Marines and to satisfy other training and education requirements as identified by 
the Commanding General, Marine Corps Combat Development Command. 


In the earliest days of MCI, the staff performed their pnmary military duties first 
and volunteered to assist in the vocational schools as a collateral duty. Today, MCI has a 
full-tme staff, Marines and civilians, dedicated to course development and administration. 
Not to stray too far from their roots, the Marines have retained collateral military duties. 
This second mission of MCI results from its administrative assignment to Marine 
Barracks, Washington, DC (MCI In-Brief, 1996): 

To support the ceremonial mission of Marine Barracks, Washington, DC 


There are seven tasks that detail the execution of the two missions (MCI Mission, 1997): 
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Plan, develop, and administer a distance training program to increase the 
specialized skill proficiency of enlisted Marines. 


Plan, develop, and administer nonresident professional military education 
courses that parallel and supplement those resident courses provided by the 
Marine Corps Combat Development Command. 


Develop, print, stock and distribute the Marine Battle Skills Training 
Handbook and a performance test for use by commanders to measure 
proficiency in the Marine battle skills. 


Design, develop, revise, stock, and distribute training materials for those tasks 
contained in the Individual Training Standards system that are the 
responsibility of the unit commander to teach. 


Develop, print, stock, and distribute additional training materials as may be 
directed by the Commanding General, Marine Corps Combat Development 
Command. 


Provide personnel and administrative support as required for ceremonial 
purposes as directed by the Commanding Officer, Marine Barracks, 
Washington, DC. 


Provide automated information support to Marine Barracks, Washington, DC. 


These tasks specify Marines as the target student population. They also assign 


responsibility for the complete training package, from development through delivery, to 


MCI. These tasks also give an indication of the organizational requirements necessary to 


successfully carry out the seven mission tasks. 


3. Organization 


MCI is operationally controlled by the Commanding General, Marine Corps 


Combat Development Command (CG, MCCDC). Specifically, the Director, Training and 


Education Division, MCCDC, provides operational guidance to MCI. MCI receives 


technical direction on Professional Military Education course content from the President, 


Marine Corps Univeisity. MCI is administratively controlled by the Commanding Officer, 
Marine Barracks, Washington, DC whois also the Director of MCI. (MCI In-Brief, 1996) 

Marine Barracks, Washington, DC is composed of a headquarters company, two 
ceremonial companies and the MCI company. The Barracks performs two evening parades 
every week during the summer and supports other ceremonial activities at the White 
House. The MCI Company of Marine Barracks provides escort and support services for 
the parades. The MCI company consists of six departments: Headquarters, Professional 
Military Education, Occupational Specialty, Logistics, Student Services, and Management 
Information Systems. {MCI In-Brief, 1996) 

The Headquarters Department has four sections that provide staff cognizance over 
MCI’s departments involved in the production and support of distance education and 
training materials. The Professional Military Education Department(PMED) provides 
courses based on Marine Corps resident PME school curricula or resident school 
prerequisites. The Occupational Specialty Department (OSD) develops and maintains 
military occupational specialty (MOS) related courses and MOS specific job aids. The 
Logistics Department (LOG) is responsible for the procurement, stock management, 
packaging, and distribution of MCI courses and training products. The Student Services 
Department (SSD) 1s responsible for the enrollment, grading, and student record 
administration of the distance education and training programs. The Management 
Information Systems Department (MISD) provides automated student administration and 
course material handting through MCI's automated information system (MCIAIS) and 


information systems support to MCI and the Marine Barracks. (MCI Mission, 1997) 
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4. Description of Services 


Since the days of General Lejeune, the Marine Corps has advocated personal 
development, and MCI has been focused on this objective. MCI has shifted from providing 
vocational and personal development courses for uneducated Marines in the early days to 
courses designed to improve the performance of today’s more educated Marines. MCI 
currently maintains six PME courses, 166 Military Operational Specialty (MOS) related 
courses, 16 MOS job sds, the Marine Battle Skills Training Handbooks and the Battle 
Drill Guide books. These materials are designed to enhance the student’s proficiency in 
their skill specialty, increase their awareness of Marine warfighting concepts and tactics, 
and prepare them for advancement to the next higher grade. (MCI Mission, 1997) 

The Marine Corps has emphasized the importance of completing MCI courses by 
granting enlisted Marines extra points toward promotion cutting scores. This incentive 
provides a more immediate benefit to an individual than college credit and education. 
(MCO1400.32, 1989) 

Professional Military Education (PME) is intended to ensure that leaders have the 
knowledge required fcr their grade, and prepare them for the next higher grade 
(ALMAR26, 1996). Marine Corps University (MCU) was established to develop and 
implement PME programs (Mundy, 1994). The Commandant of the Marine Corps 
announced, with the All Marine message (ALMAR) 256-93, that promotion and retention 
would be linked to satisfactory completion of PME requirements (ALMAR256, 1993). 
MCU has established centralized resident PME schools and provides technical guidance to 


MCI on the development of non resident PME programs. 
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MCI programs were established as the baseline for PME programs, serving as 
either a substitute for resident programs or fulfilling prerequisites prior to acceptance in a 
resident program (AI DMAR339-96). PME is so important that unless a Marine has 
completed the prescribed grade-specific PME program, resident or non-resident, he/she 
will not be considered “fully qualified” for promotion or retention (reenlistment). 
(ALMAR256, 1993) 

Whether the guidance was seen as a scare tactic or the result of a successful 
awareness Campaign, Marines responded to the non-resident educational opportunities 
provided by MCI. On a monthly basis, MCI processes 50,000 enrollments, grades 80,000 
lessons and examinations, prints and mails 200,000 individual status documents, 56,000 
completion certificates and diplomas, 1,500 Unit Activity Reports, and produces 45 
internal managemen: ,eports. The management of this student record activity is the 
responsibility of the Student Services Department. (MCI In-Brief, 1996) 


B. MCI AUTOMATED INFORMATION SYSTEM 


The mission of SSD is to support the enrollment, grading and student record 
management of the Marine Corps distance education and training programs. In support of 
its mission, SSD employs an automated information system (AIS) to automate the actions 
required to support a student in the MCI correspondence program, maintain student 
records, and produce necessary management reports. (MCI Mission, 1997) 


1. MCIAIS Svstem Overview 


The automated system, known as the Marine Corps Institute Automated 


Information System (MCIAIS), 1s a legacy system developed in the late 1970's. It uses a 


Hewlett-Packard 300( mini computer running the MPE/iX operating system. MCIAIS is 
written in the Hewlett-Packard proprietary language, "Transact", and accesses a Turbo- 
IMAGE hierarchical database. MCIAIS maintains eight non-relational databases (MCI In- 
Brief, 1996): 

e ANSREF - contains all answers and references for every exam and lesson. 


e ARCHIV - contains student records that have been inactive for 13 months or 
more. 


e DBLOGS - contains the inventory records of courses and components. 
e MCIDB - contains all student course and information records. 


© MMSDB - an extract of the Marine Corps’ Manpower database that contains 
information on all active duty Marines. 


e MSEXAM - contains information on exam Stock on-hand status. 


e REMPDB - an extract of the Marine Corps Reserve’s Manpower database that 
contains information on all class LI reserve Marines. 


e SALEDB - contains the raw data for the Statistical Analysis of Lessons and 
Exams Report (S.A.L.E. Report). 


These databases are only accessible from terminals within the Student Services or MIS 
Departments. 


2. System Interfaces 


System interface refers to the ability of two automated information systems to 
exchange data directly. While MCIAIS is a “closed” system, not originally designed to 
interface with external systems, the volume of transactions and the customer base has 
forced MCIAIS to be modified so that it can interact with certain external systems to 


reduce manual data entry. There are four systems with which MCIAIS interfaces: Marine 


Corps Total Force System, the Marine Corps Unit Diary System, Conversant and the 
Logistic Automated Information System. 

The Marine Corps Total Force System (MCTFS) is the database maintained by 
Defense Finance and Accounting Center (DFAS) in Kansas City and contains all of the 
manpower information on Marines, both active duty and reservists. Specified MCTFS data 
elements are periodically downloaded to populate MCIAIS. Specifically, MCIDB and 
REMPDB are replaced by the download. This information is used by MCI for enrollment 
validation and material] distribution. The interface is a labor intensive process that requires 
NATURAL computer language scripting and a lengthy daily download process through a 
host server at MCCT A in Quantico, Virginia. 

The MCTFES database is updated by individual Marine Corps units using an on-line 
system called the Un ; Diary. Marine Corps units submit Unit Diary transactions to 
MCTFS. MCTFS screens the transactions and posts the valid transactions to the database. 

In the case of Unit Diary transactions that request MCI enrollment, disenrollment 
and completion, the validated transactions post to an advisory database. Transactions that 
fail screening post to the unit’s Unit Diary Error/Advisory Report. MCI downloads the 
validated transactions from the advisory database. This is also a labor intensive effort that 
requires scripting in the computer language ROSCOE. 

Once the Unit Diary transactions are downloaded, they must be formatted as input 
to MCIAIS. The transactions can error out when they run the program to post the 
transactions to MCIA.iS. Each Unit Diary transaction rejected by MCIAIS must receive a 


response to notify the Marine Corps unit of the failed transaction. The unit then must 
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notify the student of tlie failed transaction, research the discrepancy, and resubmit the 
corrected transaction. 

MCI also maintains an Automated Voice Response System (AVRS) called 
Conversant. This system responds to a caller’s telephone keypad entry of social security 
number and course number and provides the caller with course status. This is an Oracle® 
database that contains copies of records for every student currently enrolled in an MCI 
course or program. The database is updated by during a weekly cycle that downloads, by 
overwriting, key data element to the Conversant database. 

The Logistics Department maintains a separate information system called 
LOGAIS. It provides «utomated management of the fiscal plan, organizational supply, 
logistic support and procurement of MCI materials. It also provides certain inventory 
management functions. MCIAIS does not interface directly with LOGAIS for inventory 
management. MCIAIS creates mailing labels with material information and the student’s 
address for material distribution. Periodically, the inventory data is manually input into 
MCIAIS. 


3. Non-System Interfaces 


Non-System interface refers to interactions between an automated information 
system and another scurce that is not an automated information systems. This section will 
address six non-system interfaces that exist outside the MCIAIS: course and program 
development, course «nd program advertisement, Unit Activity Reports, telephone 


inquiries, U.S. mail, and electronic mail. 
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MCI courses nd programs are designed in OSD and PMED respectively. All 
courseware is developed on PC’s in the respective departments. Each course is routed in 
paper form for editing and course content review. Once approved, the “proof” is prepared 
and sent to the printer for reproduction. The new or revised course is added to the course 
catalog and appropriate data elements manually entered into MCIAJIS pending receipt of 
materials. Students can be enrolled in the new course once the materials arrive and are 
stocked. 

Availability of new courses and revised courses must be advertised. Advertisement 
is done using three methods: MCI Course Catalog, MCI newsletters, and MCI mobile 
briefing teams. The MCI Course Catalog is revised and published, in paper form, annually 
making it an outdated tool for advertisement. MCI newsletters are published quarterly to 
update Marine Corps units on the availability of new or revised courses and other 
initiatives at MCI. MCI also forms a team that travels to major commands. The bnefing 
teams meet with the Marine Corps unit commanders, training officers and training non- 
commissioned officers (NCO) to provide an update of current initiatives, training on 
administrative procedures and changes to old procedures, and to solicit input on MCI 
performance. The newsletters and the briefing teams, however, only reach a small fraction 
of the customer base. 

The Unit Activity Report (UAR) is designed to give the Marine Corps unit 
Commander visibility over the unit’s participation in MCI courses and programs. It 
contains a Summary section with data compiled from enrolled students in each unit and a 


detailed transaction F.story section for each student. MCI prepares a UAR for every 
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Marine Corps unit twice a month. One report is produced in paper form and mailed to the 
unit at the end of the month. Another report is produced in digital format and stored on a 
file server for units to download. 

The UAR also serves as a tool for reconciliation between the unit and MCI. The 
Marine Corps unit training NCO verifies that the unit’s enrollment record matches MCI’s 
record reflected in the UAR. The training NCO annotates any discrepancies or expected 
changes on the UAR and returns it to MCI. Annotations would reflect that a Marine has 
enrolled in a course that has not posted, been transferred, completed a course, disenrolled, 
or is awaiting completion certification. MCI manually processes the returned UARs by 
inputting the correcticans into the student’s record on MCIAIS. 

Telephone inquiries are handled by the Student Services Department. The 
Immediate Assistance section of SSD has a number of telephones staffed with clerks to 
answer inquiries. Non-Marine students, potential students and Training NCOs can contact 
MCI with their inquiries. MCI administrative procedures advise Marine students to 
address their questions to their unit Training NCO first. If unable to answer the question, 
the training NCO will contact MCI for resolution. This procedure is intended to poems 
telephone calls to MCJ. 

MCI receives z large volume of U.S. mail on daily basis. This mail consists of 
enrollment requests, :aterial requests, inquiries, disenrollment notification, returned 
UARs, and completed lesson or course examinations for grading. The mail must be 


opened, sorted and distributed. This is a manual and time consuming process. 
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Electronic mail is another method of interacting with MCI. The volume of 
electronic mail processed by MCI has grown significantly over the last two years due to 
expanded access to the Internet and increased unit access to the Marine Corps’ Banyan- 
vines network. Electronic mail traffic consists of enrollment requests, material requests, 
Status inquiries, disenrollment notification, and returned UARs. 


4. Problems with MCIAIS 


As is typical v* many legacy systems, MCIAIS suffers from many shortcomings. It 
utilizes a "closed" non-relational database. It lacks well-defined procedures without 
underlying data or process models and the code has been poorly documented. It has over 
110 "spaghetti coded" programs that are difficult to maintain, modify, and upgrade. The 
programs have poor functionality, no statistical analysis capability, and limited "ad hoc" 
query capability. It does not support Graphical User Interfaces (GUI). These problems 
lead to further questions about data integrity and the credibility of the stored data. 

Internal problems within MCIAIS contribute to the loss of functionality within 
some of the databases. Many of the problems can not be repaired because of poor 
documentation and un‘raceable code within the legacy system. 

One example of lost functionality is the SALEDB, which provides the statistical 
analysis capability to determine the quality and effectiveness of test questions and answers. 
This capability provided critical information to the distance training instructors (DTI) 
which develop and revise the courses and examinations. 

The functionality of DBLOGS, the inventory management system, is also lost. As a 


result, the Logistics Department performs frequent cyclic inventories and manually adjusts 
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the on-hand quantity within MCIAIS to reflect changes. In the meantime, the Logistics 
Department switched ‘o another logistics management system, ATLASS, that provides 
inventory functions in addition to functions not directly related to the inventory 
management of course materials. 

The interface with MCTFS poses an additional problem. The procedure for 
downloading Marine student information includes backing up the MCIAIS MCIDB and 
REMPDB databases and replacing them with the downloaded data. Any changes that 
were entered into the two databases are not reflected in the new data. This negates any 
Marine student address changes that have been updated via telephone, electronic mail or 
UAR since the last cycle. 

The UAR does not receive the attention it was designed to attract. Due to 
MCIAIS obsolescence, inaccurate reports have been historically produced. With over 
1500 UARs produced monthly, a lot of manual data entry is required to input the 
necessary changes. 

MCIAIS data accuracy was exacerbated by the UAR cycle time. As noted, student 
history data was not always accurate. A function of the UAR is to reconcile MCIAIS data 
with actual data from Marine Corps Units. The volume of corrections requiring manual 
entry into MCIAIS from UARs invariably did not get accomplished before the next UARs 
were distributed. Training NCOs became frustrated by MCI’s apparent lack of response 
and stopped returning UARs. Without corrected UARs, additional inaccuracies 
developed. Innovative training NCOs discovered that calling MCI and submitting 


corrections directly to MCI through an immediate assistance clerk was an effective 


23 


method to correct their unit’s records. This solution heightened telephone congestion 
problems. 

At atime when MCI was experiencing its greatest challenges with MCIAIS’s 
ability to respond to the increased volume pressures as MCI courses and programs became 
requisite for promotien, the Marine Corps introduced Marine Mail. Marine Mail is an 
electronic mailbox set up for the Commandant to receive feedback about any subject 
directly from Marines. MCI problems were a common subject of Marine Mail. This type 
of visibility gave MCI an awareness of problems that they could not otherwise document 
and added impetus to find solutions. Many of the MCI problems can be attributed to the 
problems characteristic of legacy systems. 

One common problem identified was poor responsiveness and reliability when 
enrolling in MCI programs. In 1995, MCI initiated an enrollment process for active duty 
and reserve Marines using the Marine Corps unit’s Unit Diary system. This required 
detailed coordination with the programmers of MCTFS to establish prerequisite screening 
criteria and coded mc.dules. Despite the MCTFS enrollment edits, Unit Diary transactions 
that passed MCTFS screening do not pass the MCIAIS screening. By shifting the aa 
entry tasks to the unit, nearly 90 percent of enrollments are now automated. Research 
showed that it takes a unit an average of one week to process and run a Marine's 
enrollment request on the unit diary and another week for that request to be processed and 
posted on MCIAIS. There was not an effective or timely way for MCI to inform a student 
that an enrollment attempt failed. Other methods of enrollment, such as R-1 card by mail 


or the monthly Unit Activity Report, are more reliable. Those methods are also slow 
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because of MCI manval data-entry processing time. This demonstrates the difficulty of 
programming between systems with a “closed” system. (ALMARS1, 1996) 

Another problem frequently identified was that delivery of MCI course materials 
was unreliable and not timely. A survey conducted by Columbia Services Group identified 
that faster service was what MCI students wanted most from MCI (MCIAIS Brief, 1996). 
Research attributed three causes to delivery problems. (ALMARS1, 1996) 

First, the vast majority of delays for material was because MCI did not have a valid 
address or location fc. individual Marines. MCIAIS was using an outdated Reporting Unit 
Code (RUC) structure for Marine unit addresses instead of the current Major Command 
Code/ Reporting Uni: Code (MCC/RUC) structure used by the Marine Corps Total Force 
System (MCTFS). The MCTFS MCC/RUC is updated every time the unit’s address 
changes, as well as when a Marine 1s transferred. Since MCIAIS was using the RUC 
structure for mailing labels, which had not been updated for 18 years, materials were 
shipped to the wrong address. Consequently, MCI depended on the Commander's monthly 
Unit Activity Report (UAR) to identify a Marine's valid address. But only 60 percent of 
the units returned their UAR to MCI every month. (ALMARS1, 1996) 

The second cause was associated with Marine Corps unit mail handling 
procedures. MCI adcyessed course materials to the unit and the unit distnibuted the 
materials to the individuals. MCI research discovered that U.S. mail takes between three 
to twelve days to deliver course materials to units around the world. Delays beyond that 


were attributed to unit mail handling procedures. (ALMARS]1, 1996) 
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The third cause of delayed course material delivery was attributed to replacement 
of out of stock materials. MCI found that it took up to two months to have course 
materials printed. This 1s compounded by the lost inventory management functionality of 
DBLOGS. There was not a reliable method to anticipate how soon the stock of a course 
would expire. Resoluton of this problem within MCIAIS will require extensive analysis 
and coding to return the functionality of DBLOGS or establishing a direct system interface 
with LOGAIS. (ALMARS1, 1996) 

Yet another problem identified by Marine Mail was the delay in the delivery of 
final examinations. Administrative procedures required the student to complete the course 
lessons and/or a review exam and submit them to MCI for evaluation prior to issuing the 
proctored final exam. Once submitted, MCI would return the results and the final exam to 
the unit Training NC™ to administer. The same mailing address problems associated with 
course materials also hampered final examination delivery. (ALMARS1, 1996) 

The last prob!*m raised by Marine Mail was inconsistent posting of a course 
completion to the Marine’s official military record at Headquarters, Marine Corps. MCI 
research identified approximately 20 percent of course completions recorded in MCIAIS 
failed to post to the MCTFS record. When MCIAIS transferred data to MCTES, data was 
lost. This was attributed to logic flaws within MCIAIS. This is another example of how 
undocumented “fixes” in a legacy system are difficult to trace or troubleshoot. It also 
demonstrates the risk of a “closed” system interface with another system. (ALMARS1, 


1925) 


26 


MCI was established on a foundation of “vision” by far-sighted and resourceful 
innovators. Over the past ten years, the information system could barely support MCI’s 
primary mission of student record management, let alone accommodate changes necessary 
to keep pace with advances in distance learning. Innovation was spent on creating courses 
that the limited information system could support. The hallmark of vision was blurred and 
MCI’s reputation was tarnished. MCI was reacting, revising and distributing courseware 
that headquarters contrived, instead of designing innovative ways to educate Manines. 


C. MCI MODERNIZATION PLAN 


In response to the shortcomings, MCI initiated a modernization project to redesign 
and rewrite MCIAIS using "open" system architecture, both hardware and software. In 
addition, MCI began reviewing and redesigning their business processes to better support 
its mission and advances in training and education. 


1. Overview 


MCI’s modernization plan began with a requirements analysis that identified 
system design alternatives. A three-phase strategy was developed from the alternatives 
that planned for three phases of transition. 

The first phase focuses on transforming the information system from the current 
MCIAIS to a new M' ‘fAIS-I. This plans for the replacement of the “closed” legacy 
system with an open system, relational database using Fourth Generation Programming 
Language (4GL). The plan requires documentation of the data and process models. 
MCIAIS-If should maintain the same functionality of MCIAIS-I, but adds capability to 


send an electronic copy of diplomas to the Manpower Management Records Branch 
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(MMRB) of Headquarters, Marine Corps (HQMC), print mailing labels for individual 
course components, use “selected grade” of a Marine to determine enrollment eligibility, 
and has the ability to distinguish between different types of course media (i.e., paper, 
diskette, CD-ROM, etc.). MCIAIS-II should also perform statistical analysis of exams and 
ad hoc reporting for management and users. This phase includes plans to stand up a non- 
interactive Internet home Page for MCI and to upgrade the Automated Voice Response 
System (AVRS) for enrollment without operator assistance. (MCI Redesign, 1997) 

The second phase plans for enhancements to MCIAIS-II. The customer should 
have the ability to enroll or inquire over the telephone AVRS or Internet accessing 
MCIAIS-II directly without a MCI operator. MCI should have an Automated Help Desk 
installed. This phase also includes the automation of warehouse operations and complete 
integration with MCIAIS-II. (MCI Redesign, 1997) 

The third phase is focused on development of Distance Learning Centers (MCI 
Redesign, 1997). MCi’s Distance Learning Center is connected to Training and Education 
Division’s distributea learning plan. Distributed learning is the use of instructional 
technology to increase an instructor’s effectiveness and provide a student-centered 
learning environment. The distributed learning plan is based on course modernization, end 
user computers, and a network infrastructure. (Eisiminger, 1996) 


2. NPS Role 


MCI contracted with the Naval Postgraduate School to lay the foundation with the 
modernization plan’s first phase. A team of NPS students was selected by Dr. Magdi 


Kamel to conduct a Business Process Reengineering evaluation and prepare a migration 
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plan proposal. Two reports, Analysis, Design, and Prototype Implementation of a 
Contemporary Information System for the Marine Corps Institute, Preliminary Report, 
(Kamel et al., 1997) and Analysis, Design, and Prototype Implementation of a 
Contemporary Information System for the Marine Corps Institute, Final Report, (Kamel 
et al., 1997), were prepared by the NPS MCI Team and delivered to MCI. 

a. Deiiverables 

The cbiective of the NPS effort is to demonstrate a methodology that can 
assist MCI in transforming their current legacy information system into a modern 
environment that can take advantage of contemporary architectures and open 
technologies. Specifically, the NPS effort is to accomplish the following: 


1. Perform a detailed data and process requirements analysis at both the 
enterprise and the Student Services Department business area levels 


2. Review existing SSD processes and develop a new model that includes 
redesigned processes to increase their efficiency and reduce costs 


3. Develop < target hardware, software, and network architecture based 
on open systems 


4. Develop a proof-of-concept prototype to validate the proposed 
methodology 


5. Develop a data migration and change management plan for the new 
system. 


The first report, Analysis, Design, and Prototype Implementation of a 
Contemporary Information System for the Marine Corps Institute, Preliminary Report, 
(Kamel et al., 1997), develops an enterprise-wide architecture for the use of information 
systems in support of the MCI activities. The overall architecture is specified by defining 


three types of architectures: 


Zo 


Ie 


Data Architecture: Defines the major kinds of data needed to support 
MCI’s business. IDEF1X modeling is used to represent data. 


Functional Architecture: Defines the major functions of the enterprise 
needed to manage the data. IDEFO modeling 1s used to represent this 
architecture. 


Technology Architecture: Defines the technology platforms needed to 
provide an environment for the applications that manage the data and 
Support business functions. 


In addition to defining the above architectures, a set of matrices is 


developed showing the relationship between entities, functions, organization units and 


locations. The information provided by these matrices is intended to challenge 


management to think about its structure, mission, goals, and the information needed to run 


the MCI business. 


The second report, Analysis, Design, and Prototype Implementation of a 


Contemporary Information System for the Marine Corps Institute, Final Report, (Kamel 


et al., 1997), conducts a detailed business area analysis of the Student Services 


Department (SSD) and Management Information Systems (MIS) functions. It presents a 


business area analysis by defining three types of models: 


iN 


SSD Data Model: Defines the major data entities, attributes and relationships 
used by SSD. IDEF1X technique is used to represent the data model. 


SSD Process Model: Defines the major processes needed to manage that data 
and supputt the operations of SSD. IDEFO modeling is used to represent the 
process mcdel. 


SSD Technology Model. Defines the technology platform options required to 
provide an environment for the applications that manage the data and support 
the SSD business processes. 
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Specifically, the final report develops detailed data, process, and 
technology models for the SSD and MIS functions. The report also includes the associated 
design specifications for development of information systems applications to support 
Student Services, and a generated Oracle® relational database schema with associated 
triggers. 

In addition to defining the above models, a proof-of-concept prototype of 
selected applications was developed to validate the methodology, refine resulting models 
and to establish graphical user interface standards for use across all MCI applications. 


b. Team Members and Research Topics 


The effort by NPS faculty and five students formed an integrated team to 
support the redesign of the Marine Corps Institute’s Automated Information System 
(MCIAIS) using contemporary architectures, methodologies and tools. In addition to the 
two reports submitted to MCI, four theses are also presented. 

Dr. Magdi N. Kamel is an Associate Professor of Information Systems in 
the Department of Svstems Management. He has been at the Naval Postgraduate School 
since August 1988. His research interests are in the areas of application development, 
database management systems and information system architecture. Since joining the 
faculty at NPS, he has been the principal investigator on several research projects in 
application development, database management and expert systems. He is the author of 
numerous published papers on these subjects and a driving force in the NPS MCI Team 


activities. 
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Major Aaron T. Slaughter is a U.S. Marine Corps tank officer. He has a 
Bachelor of Arts in Political Science, presently in a Master of Science Degree program for 
Information Technology Management at the Naval Postgraduate School. He has been 
involved in several research projects in database management, application development 
and distributed support systems. He performed the data analysis and, working with the 
process model, produced the data model and data migration plan for the MCI 
Modernization Project. 

Major Clayton O. Evers Jr. is a U.S. Marine Corps communications officer. 
He has a Bachelor of Arts in Political Science, presently in a Master of Science Degree 
program for Information Technology Management at the Naval Postgraduate School. He 
has been involved in several research projects in network management, database 
management, application development and distributed support systems. He performed the 
system architecture analysis and, using the process model, produced the recommendations 
for the target architecture and the change management plan for the MCI Modernization 
Project. 

Commander (Select) Gerald L. Hehe is a U.S. Navy E-2C Naval Flight 
Officer. He has a Bachelor of Arts in Business Management, presently in a Master of 
Science Degree program for Information Technology Management at the Naval 
Postgraduate School. He has been involved in several research projects in database 
management, application development and distributed support systems. He performed the 


user interface analysis and, using the data, process and information models, produced a 
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prototype to demonstrate the functionality of selected applications for the MCI 
Modernization Project. 

Lieutenant Colonel (Select) Kurt A. Baden is a U.S. Marine Corps CH- 
46E pilot. He has a Bachelor of Science in Aerospace Engineering, presently in a Master 
of Science Degree program for Information Technology Management at the Naval 
Postgraduate School. He has been involved in several research projects in database 
management, application development and distributed support systems. He performed the 
process analysis and produced the information system modeling effort for the MCI 
Modernization Project. 

Major Gerald A. Peters is a U.S. Marine Corps aviation supply officer. He 
has a Bachelor of Science in Political Science, presently in a Master of Science Degree 
program for Information Technology Management at the Naval Postgraduate School. He 
has been involved in several research projects in database management, application 
development and disaibuted support systems. He performed the process analysis and 
produced the process modeling effort for the MCI Modernization Project. 


3. Business Process Model Benefits 


The focus of this thesis is directed at the reengineering of MCI and the resulting 
process models. MCi has no prior model documentation on their information system or 
business processes. The documentation provided by the two reports and this thesis can 
facilitate communication between departments within MCI. The communication can 
develop a common understanding of department processes and their inter-relationship to 


each other. 
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Such documentation is useful for understanding the magnitude of change and 
identifies the tasks required to migrate to the new process. The documentation is dynamic. 
It will, and should, change to reflect continuous process improvements. It aids in 
recognizing previous problems and ensures those problems are not repeated in new 
processes. Documentation can provide a measure of the value of a proposed innovation. 
Data collection provides situational awareness. Given a process objective of reducing cost, 
for example, data coliection would need to include the measurement of cost with which to 
compare. (Davenport, 1993) 

Since MCI has no documentation on their current system, the process model can 
serve as baseline documentation to support their current phase of modernization. It also 
provides a methodology that can be used with the subsequent phases of their redesign 
effort. The methodology employed was developed after a broad spectrum of techniques 


were evaluated and selected one as appropriate to fit MCI. 
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I. INFORMATION ENGINEERING APPLICATION TO MCI 


This chapter describes the Information Engineering (IE) methodology and its 
relevance to the MCI modernization project. The first section briefly describes the entire 
methodology. Portions of the methodology that pertain to this thesis, enterprise analysis, 
business area analysis, and business system design are discussed in greater detail. Details 
of business process reengineering methodology, process modeling, CASE tools, and data 
flow diagrams are covered in later chapters. 

A. INFORMATION ENGINEERING METHODOLOGY 

James Martin originally conceived the information engineering methodology as a 
development tool for new information systems. Since IE provides a comprehensive 
framework for satisfy) ing an organization’s information needs, the analytical techniques can 
also be applied to the reengineering of existing systems. IE encompasses all phases of life 
cycle development and implementation. IE methodology models the business process with 
three distinct but equally important models: a business data model, documenting the 
information and its source used by the business; a business process model, that 
decomposes the process into more detailed activities; and the interaction between the 
two, that defines the relationship between the data and the process models. Model 
development begins with analysis of business objectives and describes techniques to be 
applied that yield executable applications in the target environment. 


1. Information Engineering Overview 


Collectively, iiformation engineering is an integrated set of tasks and techniques 


designed to support the systems development process. Integration is the crucial aspect that 


SS 


accounts for successful outcome. Integration is fostered by a series of abstract layers 
devised to provide different views of the same business model. Within this information 
engineering framework, each layer serves as a platform from which to view the application 
systems in a different level of detail. If the system under evaluation is a new system, the 
path through the layers follows traditional system design methodology. However, if the 
methodology is applied to reengineer an existing system, entry may be made at the 
appropriate level and reengineering improvements are pushed through to the execution 
level. Figure 1 illustrates the IE layers and some typical paths through them. 


Traditional 
System 
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Figure 1. The Layers of Information Engineering and Two Methods of Negotiating Them. 
After IEF™ Technical Description, 1992. 
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The architectural layer models the organization at the highest level by examining 
the business strategy and business plan. It consists of three interlocking architectures: a 
data architecture, a process architecture, and a technology architecture. These three 
architectures can be represented as models and describe a high-level blue print for meeting 
the organization’s goals and objectives. JEF Technological Description, 1992) 
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The conceptual layer models the business process and data. Process decomposition 
diagrams and a data model record the organization’s data and activity definitions, entities, 
and business rules describing the interdependencies. These models functionally decompose 
the concepts introduced in the architectural level and provide enough detail for analysis. 

The external layer models system behavior from the end user’s point of view. It 
contains specialized information about the conceptual layer of interest to the user, such as 
screen layouts and function key assignments. 

The implementation layer is a specialization of the external layer. It maps system 
characteristics to specific hardware and software requirements. 

The execution layer is the physical application of the model developed in the 
previous layers. 

The premise of IE methodology 1s a consistent framework on which many methods 
and techniques can be applied and coexist. Conceived with software automation tools in 
mind, information engineering methodology incorporates a systems development 
framework on which to build and possesses the following characteristics: a central 
repository of modeling objects with stored meanings and defined relationships; graphical 
techniques to represent modeling objects in diagrams; clearly identified relationships 
among diagrams; and correlated definitions of modeling objects across diagrams, offering 
multiple perspectives of the same object. 

The most important purpose of the information engineering methodology is 

to provide a framework within which an integrated set of software tools 

can exist in harmony. The framework describes the logical connections and 


constraints across the architectural, conceptual, external, implementation, 
and execution layers of the development life cycle. The task order, task 


of 


Structure, diagramming conventions and semantics employed are secondary 
considerations. IEF™ Technological Description, 1992) 


It is entirely acceptable for practitioners to build alternate task lists that conform to a 
different development paradigm and still function within the underlying framework. Points 
of departure generally hinge on a preference for some practice rather than a major 
difference in vision. JEF™ Technological Description, 1992) 


2. Information Engineering Pyramid 


With the abstract framework established, Martin illustrates the information 
engineering methodology as a pyramid which has seven stages or levels: information 
strategy planning (ISP), business area analysis (BAA), business system design (BSD), 
technical design (TD), construction, transition, and production. Figure 2 illustrates the 
levels of IE. Detail increases and scope decreases as stages are accomplished. The 
methodology 1s iterative and stages 2 through 6 must be repeated for each of the business 
areas defined in stage 1. Stage 7 is not reached until the enterprise has been reengineered. 

Stage 1: Information Strategy Planning (ISP) - During this stage, the 
organization is examur ed at the enterprise level to determine information needs and build 
an information strategy plan that is aligned with the business plan. Two models are 
created: a data model, indicating what data items are needed to perform the 
organizational mission, and a high-level model of the enterprise. The enterprise model is 


divided into business areas that support the organizational mission. 
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Figure 2. The Information ae Pyramid. After Martin, 1990A. 

Stage 2: Business Area Analysis (BAA) - An As-Is process model is developed 
using process decomposition techniques for one of the business areas. The model 1s 
technology independent. 

Stage 3: Business System Design (BSD) - During this stage, a business system is 
detailed within the chosen business area. Consideration is given to how the user will 


interact with the business system, however, the model remains technology independent. 
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Stage 4: Technical Design (TD) - This is the first stage in which the hardware 
environment, operating system, and database management systems are examined. During 
this stage the BAA and BSD are tailored to the target computing environment. 

Stage 5: Construction - Dunng this stage, all executable applications are 
developed. These include programs. databases, screen formats, and user manuals. These 
applications will enable the application system to operate on the target computer 
environment. 

Stage 6: Transinon - During this stage, the new applications are installed ina 
production environment. This phased installation may involve replacing existing systems 
or portions of systems. 

Stage 7: Production - This is the final stage when all of the business areas have 
been reengineered and the enterprise realizes the full benefit of the improved business 
system. Execution of this final stage satisfies specific business needs identified during the 
initial stage. 

In addition to the seven stages. the pyramid is divided horizontally. The left side 
represents data and the nght side relates to activities. The horizontal division within each 
of the stages 1s useful tn dividing the required tasks among members of the reengineering 
team. For example. the left or data side of the pyramid is associated with the data 
modeler’s tasks of identifying data subjects and entity types. modeling the relationships, 
and normalizing the entity records. Activity tasks such as business area idenufication, 
process decomposition, and matrix development fall on the nght side. The first two stages, 


ISP and BAA, create a framework within which different teams build different parts of the 
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system at different tmes. To achieve consistency among separate modeling and 
development teams, the information collected at all levels of the pyramid is stored in a 
central repository called an encyclopedia. 

Building the framework in the top two stages takes some time. Typically, 

information strategy planning for the enterprise takes six months. Business 

area analysis takes four to six months for one area of the enterprise. 

(Martin, 1990B) 
The remaining five stages, BSD, TD, construction, transition, and production serve to 
design and implement the information system according to the plan devised during the first 
two stages. 

System construction does not wait until the framework is completely finished. 
Instead, a flexible prototype is quickly built which will allow quick retrofitting as the 
information engineering framework evolves. An objective of the IE methodology is to 


rapidly build systems that can be quickly modified by code generating CASE tools. 


B. THESIS METHODOLOGY 


While the MCi modernization project is concerned with all stages of the MCI 
enterprise, this thesis pertains only to the activity side, of the top three levels of the 
information engineerig pyramid. Figure 3 illustrates these stages. Appendix A contains a 
detailed task list for both the data and activity sides. Three team member theses cover data 
modeling and execution of the remaining IE stages of the MCI modernization project. 
Integration of all team member’s efforts result in the complete modernization plan for 
MCI. The portions of the ISP and BAA stages of the information engineering 
methodology that pertain to process modeling include: enterprise level analysis of MCI, 
business area analysis of SSD, and design SSD To-Be information system model. 
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Figure 3. The Top Three Levels of the Information Engineering Pyramid, After Martin. 


1990B. 


C. ENTERPRISE LEVEL ANALYSIS OF MCI 


Enterprise level analysis results in an overview of the organization. This overview 


is used by top level managers and reengineering team to decide how to proceed with the 


modernization plan. The overview should not be too detailed. It is used to establish a 


broad overview in a short time. Detail will be added later during the business area analysis 


Stage. 


The top level [of the pyramid] might be thought of as being like an author 
planning a book and creating its table of contents. He surveys the overall 
contents of the book and divides it into parts and chapters. He decides 
which chapters he should write first. Similarly, at the overview modeling 
stage he scopes out the overall structure and information needs of the 
enterprise, divides it into areas, and decides which area should first be 
analyzed in detail. (Martin, 1990B) 


The overview information is stored in the CASE tool encyclopedia so it can be updated 
over time and used for further analysis as detail is added. 

To create an overview for the enterprise, data and process information must be 
integrated with the business strategy. The reader will recall that the information 
engineering pyramid 1s divided horizontally with data information on the left and process 
information on the mght. Thus an enterprise level model is created when the data model 
information on the left and the process model on the night are mapped together with the 
strategic information. Mapping is achieved with matrices. The matrices are analyzed and 
clustered to define the business areas. There are three steps to this process: (1) 
identification of organizational units, locations, functions, and entity types, (2) matrix 
analysis, and (3) identification of business areas. 


1. Identification of Organizational Units, Locations, Functions, and Entity 
Types 


This first step documents the structure of the organization, identifies the functions 
and locations that perform the functions, and the major data entities. To successfully 
complete this step, it is important to identify individuals to interview and determine the 
extent of data and apptication sharing throughout the organization. Information is 
collected in several ways. Before the first interview, team members study the existing 
organizational structure, any existing business models, data dictionaries, task breakdown 
of the organization, and other documentation available about the organization. 


2. Matrix Analysis 


Once the information is gathered, matrices are created to help assess the extent of 


data and application interaction and validate the models for completeness. There are 
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several matrix combinations that can be generated from the gathered information. The four 
matrices most useful to the MCI modernization project are: organization versus location, 
organization versus function, location versus function, and data subject versus function. 
These matrices, as they pertain to MCI, are discussed in Chapter VI. 

Of the four mstrices, the data subject versus function matrix 1s the most revealing. 
This matrix maps the data subjects, developed in the data model, to the functions of the 
enterprise. The matrix is created by listing the data subjects horizontally and the functions 
vertically. Each intersection is marked to indicate whether the data subject is created, read, 
updated, deleted, or archived by the functional area. The intersections are marked with a 
“Cy” “R,” “U,” “D,” or “A,” respectively. For this reason the matmx 1s often refemeditams 
a CRUD diagram. 

A CRUD dia;‘ram is useful for two reasons. First, several problems will be 
highlighted immediately. For example, there may be functions that do not use any of the 
data subjects or, a data subject may be created by more than one functional area. 
Secondly, a CRUD matrix may be modified and clustered to reveal business areas. 

Clustering is a technique used to show which functions and data subjects fit 
naturally together. Before a CRUD matrix can be clustered it must be modified. First, the 
rows of functional areas are rearranged in life-cycle order (e.g., a course 1s first planned, 
then developed, managed, and finally archived). Next, the CRUD matrix is simplified and 
condensed into a "CR matrix." A CRUD matrix is converted to a CR matrix, by creating 
an identical function axis and data subject axis on a blank matrix. However, when filling in 


the intersections, all 'C,” "U,” "D,” and "A" entries from the CRUD diagram are replaced 
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with "C" entnes. All ‘'R" entries from the CRUD matrix retain an "R" on the CR matrix. 
The CR matrix can now be clustered. 

Clustering arranges the order of the data subjects so that as they are read across 
the horizontal axis, the data subject that is created, updated, deleted, or archived by the 
first function (reading down the function axis) is moved to the left. Then the data subject 
created, updated, deleted, or archived by the second function is moved to the left. This 
continues for all data subjects. This process can be automated with some CASE tools. The 
resulting matrix has all the "Cs" arranged on a diagonal line running from the top-left to 
the bottom-right. The data subjects can now be grouped by boxing the clusters as shown 
in Figure 4. The boxe: represent logical information subsystems with responsibility for 
creating and maintaining the data subjects. When data use falls outside of any box, the 
functions inside the box must access the data subject elsewhere, or the data must flow 
from one subsystem to another. These subsystems will later be defined as business areas. 


3. Identification of Business Areas 


As a result of clustering, eight business areas were identified for MCI: personnel 
administration, ceremonial support, program and course management, program and course 
development, student service support, warehouse and distribution, information systems 
management, and unit interaction. These business areas are described in Chapter VI. At 
this point business area analysis (BAA) techniques are applied to develop the process 


model and reengineer she business processes. 
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D. BUSINESS AREA ANALYSIS OF SSD 


The heart of business area analysis is development of the process model. The 
enterprise level analys‘s resulted in business area identification. Once the business areas are 
identified, one of them must be selected as the first to be analyzed. If resources are not 
available to analyze them concurrently, the others will be analyzed in turn until the entire 


enterprise has been searched for reengineering opportunities. The selection of the first 
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business area for analysis 1s left up to the reengineering team and should be based on the 
following factors. (Martin, 1990B) 


e Demand: pressure of demand from senior end users for new or improved 
systems, assessed need, and political overtones 


e Organizational impact: number of organizations and people affected, whether 
the organization 1s geographically dispersed, and qualitative effect 


e Existing systems: adequacy or value of existing systems, relationship with 
existing systems, and estimated cost of future maintenance 


e Potential benefit: return on investment, achievement of critical success factors, 
achievement of goals, and solution to serious problems 


e Likely success: complexity, degree of business acceptance, length of project, 
prerequisites, and nsks 


e Resources required: whether existing data or process models exist, whether a 
suitable CASE tool is installed, quality of available analysts, and funds required 


e Concurrent implementation: whether multiple BAA projects can proceed 
concurrenily, whether one project will train people who can quickly move onto 
other proj2cts, and whether an existing data administration function has already 
done adequate data modeling 

Development of the process model is accomplished through functional decomposition. 


Process modeling and functional decomposition are discussed in Chapter V. 


1. As-Is Process Model 


The As-Is process model emerges from the process decomposition of each 
business area. Much of the material gathered during the enterprise level analysis (e.g., 
MCI department briefs, user interviews, training manuals, and management reports, etc.) 
is further scrutinized to define the lower level processes in detail. Business areas are 


broken down to their primitive level processes with the aid of a CASE tool which provides 
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a repository for all of the processes, their definitions and relationships. The process model 
includes both manual and automated processes. The As-Is model consists of three parts: 
(1) process node tree diagrams indicating process hierarchy, (2) process decomposition 
diagrams depicting the processes and the data or material they share, and (3) definitions of 
all of the symbols on each of the diagrams. IDEFO techniques are used for As-Is process 
modeling and discussed in Chapter V. 


2. Reengineer the SSD As-Is Process Model 


Once the As-!s process model is created and validated by the process owner, the 
reengineering principles that best fit the situation, are applied. The goal of reengineering is 
to reorganize the organization around the key processes performed by the business. Most 
reengineering methodologies investigate ways to eliminate non-value-added processes, 
minimize redundant data entry and storage, integrate or combine similar processes, 
implement data sharing, and automate manual processes. Business process reengineering 
methodologies are discussed in Chapter IV. 


3. To-Be Process Model 


The To-Be process model is the result of reengineering the As-Is process model. 
The To-Be model is cften a streamlined version of the As-Is process model, but in all 
cases represents a muie efficient reincarnation of the former organization. Like the As-Is 
process model, the To-Be process model is modeled using an appropriate modeling 
technique and consists of three parts: (1) process node tree diagrams indicating process 


hierarchy, (2) process decomposition diagrams depicting the processes and the data or 
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material they share, and (3) definitions of all of the symbols on each of the diagrams. 
IDEFO techniques are used for To-Be process modeling and discussed in Chapter V. 


4. Matrix Analysis 


Matrix analysis techniques are again applied to validate the process and data 
models and lay the ground work for the next level of the information engineering pyramid, 
business system design. Once the To-Be process model and the data model are complete, 
a matrix is created that shows the relationship between business processes and data model 
entities. The matrix is first generated as a CRUD, converted into a CR matrix and then 
clustered as described earlier. The matrix analysis is used for three purposes: (1) to ensure 
that all of the data model entities are created, read, updated, deleted, and archived by the 
process model, (2) to ensure that the data model contains only the entities required by the 
process model, and (3) to support the clustering of related processes into groups that 
reveal candidate applications to be distnbuted to the workstations in the overall 
client/server system. Five applications were identified for SSD during this step: student 
servicing, unit servicing, grading, registrar, and executive summary information. 


E. SSD TO-BE INFO SYSTEM MODEL 


The information system model represents that portion of To-Be process model that 
transfers or transforms data within the system. Manual processes are not included. Like 
the case of the As-Is and the To-Be business models, a visual presentation is more useful 
than a verbal description. IDEFO can be used for modeling the information system. 
However, a more common form of information system model depiction is with a logical 


data flow diagram (DD). The information system model integrates the data model details 
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with the automated processes and presents them in a form that can be interpreted by a 
programmer developing code for a prototype system. The information system model 
consists of three parts: (1) DFDs depicting information system process decomposition, 
(2) definitions of all of the symbols on each of the diagrams, and (3) process specifications 
at the primitive process level. Data flow diagramming is discussed in Chapter V. 


F,. CASE TOOL 


Information engineering 1S made practical by the use of a CASE tool. It is 
important to choose a tool in which planning, analysis, design, modeling, and construction 
modules are integrated and share the same encyclopedia. The metadata in the encyclopedia 
resulting from the ISP study is a valuable asset and should be updated periodically. As the 
strategic goals or objectives of the business change, the information in the encyclopedia 
should also be changed. In this way, the business model remains current and available for 
periodic review. The ISP should be reviewed periodically along with goals, problems, 
critical success factors, and technology impact effects to ensure they remain in synch with 
the strategic vision and business plan. A suitable CASE tool facilitates this analysis. CASE 


tools are discussed in Chapter V. 


SO 


IV. BUSINESS PROCESS REENGINEERING METHODOLOGY 


This chapter presents a discussion and comparison of business process 
reengineering (BPR) saethodologies and their relevance to the MCI modernization project. 
The first section introduces business process reengineering concepts. The second section 
briefly describes four prominent BPR methodologies. The third section compares the 
methodologies. Finally, the fourth section evaluates each of the BPR methodologies in the 
context of MCI and selects the BPR methodology best suited for reengineering the 
Student Services Department of the Marine Corps Institute. 


A. REENGINEERING METHODOLOGY OVERVIEW 


There are many accepted reengineering methodologies. Some of the more notable 
methodologies include: Process Innovation, Business Process Improvement, Business 
Process Redesign, ani Business Process Reengineering. Each methodology’s approach 
differs by the degree «.f change and duration of implementation. Although the techniques 
of execution vary, the goal is ultimately the same: reorganize the organization around the 
key processes performed by the organization. Most reengineering methodologies 
investigate ways to eliminate non-value-added processes, utilize information technology to 
minimize redundant data entry and storage, integrate or combine similar processes, 
implement data sharing, and automate manual processes. 

The generic term business process reengineering has evolved from Michael 
Hammer’s original radical overhaul methodology to include the full spectrum of many less 
severe process improvements. Figure 5 illustrates the fact that as the process modifications 


become more signifi ant there is a also an increase in project cost, 
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expectations, risk of failure, and time to complete the venture. A survey of four 
methodologies provides a broad spectrum of possibilities and capabilities for reengineering 
the Student Services Department at MCI. Four methodologies are briefly discussed in the 
succeeding section. While each methodology is unique in its detailed execution, they all 
share common elements: organizing, team building and planning, documentation of the 
Current process, analysis, redesign, information technology application, implementation 
and, monitoring. 


B. REENGINEERING METHODOLOGY REVIEW 


Four BPR methodologies were reviewed as candidates for the MCI modernization 
project: Hammer and Champy’s Business Process Reengineering, Thomas Davenport’s 
Process Innovation, H. James Harrington’s Business Process Improvement, and DoD’s 
Functional Process Improvement (FPI). Each is briefly described below. The order in 
which the methodologies are discussed represent the operationalism of the BPR process, 
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beginning with Hammer and Champy’s principles and progressing to the Functional 
Process Improvemen. designed to be implemented with an integrated suite of CASE tools. 
Details of each methedology can be found in Appendix A. 


1. Hammer and Champy 


Michael Hammer was the first to popularize the concept of reengineering when he 
wrote the article, “Reengineering Work: Don't Automate, Obliterate" (Hammer, 1990) for 
the Harvard Business Review. Hammer maintains that traditional “total quality” 
approaches to process improvement are insufficient in today’s Competitive market. 
Hammer’s point 1s actually a caution to all reengineering projects not to blindly apply 
technology before analyzing the business process first. Misapplication of information 
technology 1s often a hindrance and Hammer counters that an organization must first 
recognize its problen « and then “dramatically” overhaul the way it does business. This 
dramatic overhaul requires a completely fresh approach in order to accomplish the 
objective. All preconceived notions of organizational structure, decision making, and final 
product delivery must be ignored and a new way of doing business must be conceived. 

In 1993, Hammer co-authored Reengineering the Corporation with James 
Champy. In the book they formally defined reengineering as “the fundamental rethinking 
and radical redesign of business processes to achieve dramatic improvements in critical, 
contemporary measures of performance, such as cost, quality, service, and speed” 
(Hammer and Cham,,y, 1993). Reengineering requires the organization to consider the 


final product of its e.1orts, and include information technology as a requirement of 
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success. While information technology can be very useful, it should not be applied 
haphazardly. 

Hammer and Champy’s approach to reengineering 1s to start with a clean slate and 
concentrate on goods and services producing processes, seeking to provide orders-of- 
magnitude level improvement as opposed to incremental improvements through total 
quality management principles. Their approach stresses the need for competition analysis, 
customer feedback, and strong organizational desires to succeed. While they lay out the 
principles of reengineering and provide numerous examples of corporations that 
successfully diagnosed and corrected their own quality and market performance 
deficiencies, Hammer and Champy shy away from individual business task analysis and do 
not provide many concrete techniques that reengineering teams can apply to their own 
organizations. While the case studies illustrate the successful application of Hammer and 
Champy’s reengineering principles, each of the corporations is different and the individual 
techniques applied by each to turn itself around may not be appropriate for another. 


2. Thomas Davenport 


Thomas Davéeaport’s Process Innovation concentrates on process analysis. Process 
Innovation is dividec .ato five phases: identify processes for innovation, identify change 
levers, develop process vision, understand existing processes, and design and prototype 
the new process. Davenport’s five phases guide the reengineering team through a 
thorough search for processes in need of streamlining, with particular interest in the 
application of information technology. Like Hammer and Champy, Davenport uses a 


“clean slate” approach and stresses that incremental improvements to business processes 
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are not enough in today’s intensely competitive global markets (Davenport, 1993). 
Davenport’s goal is to make the organization more profitable, efficient and more satisfying 
to customers by any means, be it organizational structure changes, application of 
information technology, or changing the very nature of the business. Davenport’s 
methodology contains more techniques than does that of Hammer and Champy. 

Phase I, identify processes for innovation, begins with developing a list of the 10 - 
20 key organizational processes, defining these processes and noting any interdependence 
between them. Each process on the list is then examined to determine its strategic value to 
the organization’s goais, health, and the political and cultural pressures associated with it. 
Phase I concludes with a prioritized list of candidate processes for reengineering. The 
process that is most central to the company’s overall goals, most problematic, and has the 
political backing of organization leaders should be the first entry on the list. The other 
processes will follow as resources permit. 

Phase I, identify change levers, surveys the potential technological and human 
opportunities available to change the process. An important aspect of this phase also 
examines potential constraints and barriers to process change. Examples of constraints and 
barriers include, “strict hierarchical structures, cultures unreceptive to innovation, and 
general organizationai ngidity or inability to accommodate change” (Davenport, 1993). 
Both opportunities and constraints are considered and the best change lever is selected. 

Phase II, develop process vision, includes identification of measurable objectives 
and characteristics of the process, and formulation of specific process attributes. First, the 


organization’s current vision and business strategy are compared to the company’s desired 
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future state. Second, customer feedback is collected to correlate effort and results. The 
process 1s then benchmarked against similar processes of competitors. New performance 
measures are then created for the process that will satisfy current customers, take the 
organization where it wants to be, and meet or exceed competition quality. 

Phase IV, understand existing processes, documents and models the existing 
process to use as a baseline for evaluating proposed process improvements. To accomplish 
this, the current process 1s assessed with the improved process criteria developed from the 
previous phase. Shor.omings not only in process work flow, but organizational structure, 
information infrastructure, and employee skill levels are identified and short term 
improvements are explored. 

Phase V, design and prototype the new process, \s the implementation stage. 
Design alternatives are enumerated. After assessing each alternative for feasibility, risks, 
and benefits, the preferred redesign 1s prototyped. Following successful prototype 
evaluation, a migration strategy is developed and the improved process is implemented. 


3. H. James Harrington 


H. J. Harrington’s five phases of Business Process Improvement (BPI) are less 
radical than that of Hammer and Champy, or Davenport and reflect more of a total quality 
approach. Harringtor .heorizes that management spends too much time correcting 
problems that should not have occurred in the first place. Business managers should now 
be responsible for developing business and manufacturing processes that work error-free. 
Existing business processes should be redesigned to error-free standards. Throughout the 


entire methodology, Harrington emphasizes the necessity of proper training for those 
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executives and employees who perform the analysis and process reengineering. Harrington 
addresses five phases: organizing for improvement, understanding the process, 
streamlining, measurement and control, and continuous improvement. 

Harrington’s objective of Phase 1, organizing for improvement, is to ensure 
success by building leadership, understanding, and commitment (Harrington, 1991). 
During this phase, the organization appoints an executive improvement team to act as a 
steering committee and a business process improvement czar to be responsible for 
overseeing the projec: through to fruition. This high-level management group determines 
the scope of the projest, establishes the level of organizational commitment, and appoints 
the process improvement team (PIT). Members of the PIT are appointed from the 
departments who own the processes being reengineered. The PIT members carry out the 
modeling, analysis, and reengineering of each business process. 

Phase II, understanding the process, is the data collection and modeling stage of 
the methodology. PIT members examine business strategy, interview customers, define 
and model business processes with flow charts and documentation to develop what is 
known as an As-Is bu siness model. 

Phase Ill, streumlining, is where the actual reengineering takes place. PIT 
members seek to ider «ify process improvement opportunities by eliminating bureaucracy 
and no-value-added activities, simplifying the process, reducing process time, upgrading 
equipment, standardizing data, or automating activities (Harmington, 1991). 

The objective of phase IV, measurement and control, is to implement a system to 


control the process for ongoing improvement (Harrington, 1991). Once the process has 
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been reengineered, process targets are established by which performance of the improved 
process will be measured. 

Phase V, continuous improvement, embraces total quality principles by 
continuously monitoring the improved business process for continued excellence. Periodic 
examination of the process performance is benchmarked against the best practices in 
industry and if need be, the process improvement cycle 1s repeated. 


4. DoD Functional Process Improvement (FPI) 


The functional process improvement program was established in January 1992 by 
the Corporate Information Management (CIM) Information Technology Policy Board to 
assist Department of Defense agencies in making improvements to their business 
processes. FPI is the most comprehensive of the BPR methodologies discussed thus far. 
The CIM mandates thst FPI create As-Is process models with the IDEFO technique. The 
FPI also evaluates po-ential process improvement alternatives using activity based costing 
techniques. During the final phase of the FPI methodology, a functional economic analysis 
(FEA) is prepared by the reengineering team for the decision makers. A FEA 1s a 
“business case” that presents the alternatives in business and economic terms more 
understandable to the majority of senior executives. 

FPI attempts to integrate six underlying principles: strategic/business planning, 
activity modeling, data modeling, activity based costing, economic analysis, and best 
business practices. Six major steps describe the FPI methodology. The methodology is 


further subdivided into enabling tasks described in Appendix A. 
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a. Underlying FPI Principles 


Strategic/Business Planning - Strategic planning provides a set of business 
goals and defined requirements expressed in terms of customer needs within the context of 
agency mission, vision, values, and beliefs. A strategic plan defines what an organization is 
all about, who it will serve, what needs it will fulfill, and under what terms it will operate. 
A unique requirement of the governmental hierarchy is that the strategic plan must be 
consistent with those of higher authority, and no element of the strategic plan can conflict 
with the mission, visica, values and beliefs expressed by higher authority. On the other 
hand, business planning provides a set of business objectives with appropriate performance 
measurements and a comprehensive list of required output product and service features 
that will meet the customer needs defined in the strategic plan. The business plan should 
focus on what the organization will do to satisfy the goals, needs and requirements 
expressed in the strategic plan. 

Activity Modeling - Activity modeling is a technique used to understand 
the business process. Process decomposition is used to decompose a process into 
activities. The result is a multi-level diagram representing the business process with all of 
the inputs, outputs, c/.itrols, and mechanisms affecting the final product or service. This 
final model is referred to as the As-Is process model. The As-Is model will be 
reengineered to become the To-Be process model. The To-Be model will eventually be 
used to develop a prototype and implement the improved business process. 

Data Modeling - Data modeling is a technique for systematically describing 


what information the organization needs to perform its business process. Like activity 


59 


modeling, an As-Is model 1s first produced, describing the current data environment. The 
As-Is data model is then analyzed and compared with the As-Is process model to ensure 
that all required data is included and conversely, that no redundant or unused data is 
collected or maintained. A data model shows all of the entities, attributes, and 
relationships among the entities. Entities are objects which an organization values enough 
to keep data about. Attributes are the data items recorded about the entities. Relationships 
between and among entities are often expressed as business rules. To ensure compatibility 
with the process mod¢ling technique, FPI mandates that data modeling be done with the 
IDEF1X technique. A complete description of data modeling is contained in A Relational 
Database Model and Data Migration Plan for the Student Services Department at the 
Marine Corps Institute (Slaughter, 1997). 

Activity Based Costing - Activity-based costing (ABC) is a technique that 
allows unit cost determination of producing goods and services. ABC 1s an extension of 
activity modeling. IDEFO activity modeling is designed to record activity cost data. Unit 
cost figures resulting from ABC are the basis for economic analysis. 

Econc-nic Analysis - Economic analysis provides the capability to assess 
the costs and benefits associated with each process improvement, taking into account the 
life cycle characterist'.s of each investment. The As-Is process model is used as a baseline 
by which all competing alternatives are compared. Economic analysis presents the decision 
data in equally valued dollars (taking the time value of money into consideration), as well 
as the risks associated with making decisions about future conditions and performance. 


Economic analysis is presented as a FEA. 
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Best Business Practices - Benchmarking proposed process improvements 
against recognized industry leaders is the technique used to ensure the proposed 
improvements are up to par with the best alternatives available. 


b. FPS Methodology 


The fuactional process improvement methodology consists of these steps: 
define, analyze, evaluate, plan, approve, and execute. Each of the steps integrates the 
underlying principles to cover the entire BPR project from start to finish. 


Define - During this phase, a framework is established by defining baselines, 
objectives, and strategies for the process. Activity and data modeling begin in 
preparation for the analysis phase from which to begin process improvement. 


Analyze - This phase proposes the improved process alternatives. The As-Is 
process model is analyzed to examine all processes that make the current process 
more effective and efficient. ABC data is gathered and modeled for each activity of 
the process decomposition. 


Evaluate - Alternatives are compared against the baseline processes in terms of 
both function and cost. 


Plan - A migration plan is developed for each of the contending improvement 
alternatives. rhe plan should be comprehensive and cover the impact on costs, 
benefits, risk, and the effect on the organizational structure. 


Approve - Pertinent data from the definition, analysis, evaluation, and planning 
phases are assembled for presentation of each of the improvement alternatives to 
the highest level executive decision makers. This presentation is in the form a 
Functional Economic Analysis (FEA). A FEA is similar to a traditional economic 
analysis. Both evaluate the economic feasibility of a project using classic economic 
analysis techniques. The primary difference between them 1s scope. While an 
economic analysis usually covers a single initiative an FEA covers the life-cycle 
aspects and the overall effect of the intended change on the entire organization. 


Execute - Once approved, the new system is implemented in accordance with a 
DoD-wide technical integration and migration strategy. 
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C. SELECTION CRITERIA 


The selection of a reengineering methodology is based on perceived conditions of 
the business environment and often depends on the degree of interest by senior 
management and the amount of risk the organization is willing to take toward 
implementing redesign efforts. Understanding the business environment and the 
organization will aid the reengineering team in the selection of a methodology. Before 
selecting a methodology, the organization and analyst must consider reengineering 
categories, reengineering ideals, reengineering principles, and reengineering roles. 

1. Reengineering Categories 

Reengineering methods can be grouped into three categories: crisis, goal oriented 
and life-cycle. (Koulopoulos, 1995) 

Crisis reengineering is a response to pressures, internal or external, which 
necessitate a change to current business operations. This type of redesign is less likely to 
follow a formal methodology. High level sponsorship within the organization 1s not 
required because change must be effected regardless of the method. Crisis reengineering 
carries a high degree cf risk since it is often unplanned. 

Goal oriented reengineering seeks to substantially change the fundamental 
business objectives. This strategy radically transforms the organizational processes by 
disregarding all present processes and designs how the company will function in the 
future. This method requires high level sponsorship due to the inherent risk of eliminating 


familiar processes and implementing futuristic procedures. 
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Life-cycle reengineering is strategic and continuous. Incremental changes are 
made constantly to alter the business direction. The redesign effort establishes a baseline 
assessment of how business is conducted. Managers then use metrics to establish value for 
each task and examine alternatives that will improve the processes. Improvements, radical 
or conservative, to current processes are made where necessary. This category of 
reengineering requires a high-level champion to provide continuity and ensure adequate 
program funding. Life-cycle reengineering is considered the safest for organizations 
without the resources or the capacity to assume the higher levels of risk inherent in the 
other categories. 


2. Reengineering Ideals 


Hammer and Champy list four themes that are preeminent in successful 
reengineering efforts (Hammer and Champy, 1993): process onentation, ambition, rule- 
breaking, and creative use of information technology. All four reengineering ideals have 
application to the MC‘: modernization project. However, due to cultural and budgetary 
constraints, reenginee:ing at MCI was narrowly focused within the Student Services and 
Information Systems Departments, the primary creator and administrator of the data. 

Process Orieniation - Organizational perspective is influenced by the management 
theory in vogue. The industrial age focused on task organization and work simplification 
in an assembly line. The information age centered on gathering and distributing 
information. The current trend in “down-sizing”’ or “‘right-sizing” leads to a perspective 


focusing on processes and process improvement. 
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Task-oriented jobs in today’s world of customers, competition, and change 
are obsolete. Instead, companies must organize work around process. To 
achieve significant productivity and quality improvement, an entire process 
must be analyzed, not just the work steps within a department of an 
organization. (Hammer and Champy, 1993) 


Ambition - All business processes within an organization must be considered 
candidates for reengineering. Reengineering teams must be ambitious, seeking innovative 
ways to improve all business processes. No area should be protected from this scrutiny. As 
noted, only one third of the whole business would be considered for reengineering as part 
of this modernization project. 

Rule-breaking - Business rules are efforts by an organization to standardize 
operating procedures. Reengineering teams should consider new ways to significantly 
improve productivity without allowing existing rules to limit their consideration of 
alternatives. This requires a commitment by management to sever their reliance on the 
comfort of established procedures. Considerable effort by MCI was put into eliminating or 
streamlining the business rules and regulations attached to student’s course enrollment. 
This reduction in business rules simplified prototype coding and will simplify 
implementation codin,: and code maintenance in the future. 

Creative use of information technology - Information technology (IT) and its rapid 
advances play a significant role in BPR. Thomas H. Davenport identifies nine areas where 
BPR can benefit from IT (Davenport, 1993): 


1. Automation - IT can automate tasks reducing redundancy of data entry 
improving quality, integrity and speed. 


2. Information - Electronic transfer of information and documents via 
telecommunication systems or networks decreases process completion time 
and facilitates enhanced work coordination. 
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3. Sequence - IT, using databases and groupware, allows parallel work 
accomplishment, improving the sequencing of tasks and decreasing overall 
business cycle time. 


4. Tracking - IT enables the close monitoring of process objects and their 
completion status. 


5. Analysis - The data manipulation, storage and presentation capabilities of IT 
allow for the critical analysis of processes and their supporting information. 


6. Geography - Telecommunications networks allow the sharing and transfer of 
information between geographically dispersed organizations. 


7. Integration - Database and groupware technologies allow multiple personnel to 
work together on a single project. 


8. Intellect - IT, such as expert systems, allow the capture and preservation of 
corporate knowledge and procedures. 


9. Disintermediation - Electronic data interchange decreases the requirement for 
person-to-person interactions and reduces the number of people involved in a 
process. 


3. Reengineering Principles 


Reengineering principles represent the best reengineering practices collected from 
the industry and disti!‘ed to their very essence. Principles are not limited to manual and 
automated processes but may also be applied to the cultural aspect of reengineering. 

Process Princivles - In any organization, there will be manual and automated 
processes subject to iniprovement. These principles are general and can guide the 
reengineering team (Hammer and Champy, 1993): 


e Combine several jobs into one to involve fewer people in the completion of a 
process. 


e Let the worker make decisions. 


e Perform the steps of a process in a natural order. 
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e Designate a person who will be responsible for controlling and improving each 
process. 


e« Create multiple versions of a process. Each version should be dependent upon 
a particular outcome of a decision made by the person performing the task. 


e Perform work where it makes the most sense. 


e Reduce checks and controls on work. Only perform tasks that add value to the 
overall process. 


e Provide a single point of contact to business customers. 


Russ Linden delineates these additional principles (Linden, 1993): 


e Substitute parallel for sequential processes to decrease business cycle time. 
e Capture information once, at the source. 


e Bring “downstream” information “upstream” so that all required information 
for the entire process is gathered and entered into the system at the start. This 
will decrease data gathering and communication times. 


e Ensure a continuous flow of value-adding activities. Get rid of tasks that do 
not produ-ce something of value to the customer. 


e Organize around outcomes, not functions. Ensure there is an important 
business reason for conducting a process or task. 


e Redesign first, then automate. Do not automate first and simply speed up a 
faulty procedure. 


e Know why apiece of paper enters the system. Substitute technological 
interfaces where face-to-face interactions are not required. 


Cultural Principles - Effective application of these principles dunng the 
reengineering process will result in the transformation of numerous aspects of the 
organization (Hammer and Champy, 1993): 

e Jobs change from simple tasks to multidimensional work. 


e Organizat onal structures change from hierarchical to flat. 
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e Managers change from supervisors to coaches, shifting emphasis from 
oversight and control to facilitator, enabler and educator. 


e Executives change from scorekeepers to leaders. 

e Values change form protective to productive. 

e People’s roles change from controlled to empowered. 
e Job preparation changes from training to education. 


e Focus of performance measures and compensation shifts from activity to 
results. 


e Advancement criteria change from performance to ability. 
4. Reengineering Roles 


Finally, the organization itself determines the outcome of any reengineering effort. 
A BPR consultant may be used to advise the organization on how to accomplish a 
reengineering project but it is the personnel within the organization who actually 
reengineer the business processes. Employees know and understand the business and 
these personnel fill key roles during the redesign project. (Hammer and Champy, 1993) 


Leader - The leader is an executive level manager with oversight responsibility. 
The leader must be able to influence reluctant employees to embrace the change 
program. The leader is the steward, creating the corporate vision while ensuring 
managerial and financial continuity. 


Steering committee - The steering committee is a group of senior managers who 
define the reer-gineering strategy, determine project priority, allocate resources and 
assist the reengineering teams problem resolution. 


Reengineerin. czar - The reengineering czar is the organizational expert on 
reengineering ~rocedures and tools and must be able to oversee the project from 
beginning to eid. The czar must support each process owner and the reengineering 
team as well as coordinate all reengineering activities. The czar is the technical 
interface between the reengineering team members and the leader. (Hammer and 
Champy, 1993) 
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Process owner - The process owner is a senior leader responsible for the effective 
and efficient function of a particular business process. The owner provides the 
reengineering team with process information during the change effort and becomes 
responsible for its implementation and continued optimization. 


External consultant - The use of an external consultant during a reengineering is 
often recommended for several reasons. It may be difficult for managers inside the 
enterprise to take a detached view point. A skilled external consultant can often 
clearly see and diagnose problems in an organization that would go unnoticed by a 
manager busy with day to day operations. Consultants are also useful as experts in 
reengineering methodology application, prototype development, data and process 
modeling, critical success factor analysis, and other aspects of reengineering that 
organic organizational mangers may not possess. Not only is it important for a 
consultant to have technological expertise but they should also exhibit the personal 
relationship skills necessary for them to integrate with top management and the 
reengineering team. Together they will accomplish the reengineering. 


The actual reengineering process is performed by the reengineering team. The 
team should be comprised of personnel from various functional areas, especially one 
experienced in current information technology advances. There should be members from 
outside the process under review to provide objectivity and interface awareness. Process 
analysis, modeling, and redesign are time consuming efforts and should be done as quickly 
as possible to avoid “paralysis by analysis.” The team members should be assigned to the 
project on a full-time basis, but not less than 75% commitment level is required. (Hammer 
and Champy, 1993) 


D. BPR TECHNIQUE COMPARISON 


All of the surveyed methodologies are similar in composition, but differ in 
sequence and level of detail during execution. Figure 6 places the surveyed methodologies 
on the BPR spectrum introduced earlier in the chapter. Each of the methodologies has 


individual merits but there is not one methodology perfectly suited for every situation. For 
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Figure 6. BPR Spectrum with Selected Methodologies in Place. 





comparison, Table 1 summarizes the main stages of each methodology. Each has 
strengths, weaknesses, and other characteristics that are worthy of analysis before 
selecting the most appropriate methodology for the MCI modernization project. 

The common thread running through all of the methodologies is that each of them 
accomplishes the basic steps of traditional system development stages: planning, analysis, 
external design, internal design, and construction. The difference in the methodologies 1s 
the degree of detail they prescribe. Table 2 compares the methodologies and serves to 
highlight the similarir es and differences between them. 

The methodolugies can be grouped into two categories of reengineering: radical 
and incremental. Radical reengineering “...means disregarding all existing structures and 
procedures and inventing completely new ways of accomplishing work (Hammer and 


Champy, 1993). Incremental reengineering, considered by Hammer and Champy to not 
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Table 1. BPR Methodology Summary. 


even qualify as “reen-vineering,” is based on the total quality approach introduced by 
Demming in the 1950s. Incremental methodologies analyze existing processes and seek to 
improve productivity with more conventional, less radical changes to organizational 
structure and application of information technology. Both radical and incremental 
reengineering methodologies prescribe process improvement but differ in the scope of 
their methods. 

The methodologies of Hammer and Champy, and Davenport both fall into the 
radical methodology category. The methodology of Hammer and Champy is the most 


radical and the least detailed. Hammer and Champy strive for dramatic improvement and 
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“dramatic improvement demands blowing up the old and replacing it with something new” 
(Hammer and Champyv, 1993). 

While Hammer and Champy fail to provide techniques that reengineering 
practitioners might use to accomplish the task, their methodology has been distilled into 
the principle pillars that all other reengineering methodologies are built on. Hammer and 
Champy’s intended audience is the chief executive level and is full of motivating rhetoric 
and successful examples from the business world. At the CEO level, detailed knowledge 
of techniques are not necessary. One of Hammer and Champy’s reengineering principles is 
that reengineering projects often fail due to lack of top management support. Hammer and 
Champy serve to eduvate and motivate, top executives empowering them to ask questions 
and champion their 0.vn reengineering cause. The importance of IT application into the re- 
invented corporation z ad reengineering team is also emphasized. 

Davenport also advocates IT application and provides more detail than Hammer 
and Champy but not enough for a reengineering team to rely on for complete 
reengineering. Like Hammer and Champy, Davenport’ process innovation expects 
reen gineering to net substantial increases in productivity and profit by starting with a 
“clean slate” and effecting a one-time, top-down, broadly cross-functional fundamental 
change to the way the organization conducts business (Davenport, 1993). Davenport 
suggests detailed tecl:niques to be used for analyzing business environment, identifying 
candidate processes for innovation, gathering performance objectives, and applying IT 


solutions. Davenport s methodology briefly mentions the role of top management during 
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reengineering and list industry success stories but does not elaborate on techniques to 
foster reengineering leadership or organizational reengineering roles. 

The risk of failure for such radical and sweeping changes during a short time to an 
organization 1s much figher than the less radical, total quality based incremental process 
improvement methodologies: business process improvement, and functional process 
improvement. Both of these methodologies are rich in practical techniques that can be 
readily applied by reengineering practitioners. 

Harrington’s methodology offers comprehensive coverage from planning to 
implementation. He furnishes guidance on how to organize the organization, select teams, 
collect and analyze data, reengineer the process, and continue monitoring the improved 
process after implementation. Harrington emphasizes the importance of training the 
reengineering team and executive leaders prior to beginning the project to reduce the risk 
of failure. Specific tecnniques are augmented by examples of analytical methods (e.g., 
graphs, charts, matric«s, etc.) to assist the practitioner with decision making throughout 
the process. It is implied that these tools could be implemented with computer software 
but Harrington does not specifically address the use of any CASE tools. 

The last methodology surveyed, functional process improvement relies on CASE 
tocls for smooth operation. The use of CASE tools that model processes in IDEFO, linked 
with ABC analyzing software are mandated as is software specifically developed to 
prepare a FEA. 

In typical Department of Defense fashion, the functional process improvement 


model with its 25 steps prescribing still more detailed and specific tasks could be labeled 
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the most comprehensive methodology. Like BPI, FPI offers comprehensive coverage from 
planning to implementation. Flexibility is limited, however, by the hierarchical constraints 
inherent in government bureaucracy. For example, FPJ planning tasks include briefing the 
upper echelon about reengineering theory, principles, risks, and benefits but do not 
mention reengineering team composition or reengineering leadership roles. FPI presumes 
that the innate hierarchy will suffice. FPI data gathering and analysis techniques focus on 
activity based cost accounting principles and culminates with the presentation of the FEA 
to the top level of the aierarchy. Once the ultimate decision as to which alternative to 
choose is made, the innate hierarchy again 1s presumed to oversee the execution Stage. 
This methodology appears to be driven by the process and all reengineering decisions 
made exclusively in terms of lifecycle costs with inadequate attention to implementation 
and monitoring. Although the methodology is inflexible, the concept is sound and 1s well 
supported in terms of software support and training. 


E. REENGINEERING METHODOLOGY SELECTION 


Central to the success of the modernization project is selection of a suitable BPR 
methodology. Of the many methodologies available four candidates were evaluated. When 
assessing a methodoluzy’s fit to the MCI modernization project, each of the BPR 
methodology selecticy. criteria, discussed in the second section of this chapter, was 
considered in the business environment context at MCI. 


1. Reengineering Methodology Characteristics 


Before selecting the reengineering methodology best suited for the particular 


business environment. it is useful to specify criteria with which the reengineering team can 
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compare competing methodologies. The DoD Manual for BPR identifies the following 


characteristics of an effective methodology for change management (DoDInst 8020.1-M, 


9S): 


Completeness - The methodology must provide steps that direct a business process 
improvement procedure from establishment to implementation. 


Applicability - The methodology must be able to be used on any process of the 
business. 


Friendliness - The procedure must be easy for all personnel, including non- 
technical workers and managers, to learn and understand. 


Consistency - it must be the only methods used to conduct reengineering within 
the organization. This will allow in-house reengineering expertise to be developed. 


Supportable - The reengineering procedure must include detailed documentation, 
training courses and project management tools. 


Successful - The methodology should have a record of success and these cases 
should be available to guide the actions of the reengineering team. 


Documentable - The procedure must produce process documentation as it 1s used. 


Enabled by Tools - The method must be supported by automated tools that help to 
ease the reengineering workload and enable process documentation and 
measurement. 


2. BPR Technique Selection for MCI Modernization Project 


As initial information was gathered about the current information system and 


business process at MCI, research was initiated into the most appropriate business process 


reengineering methodology, modeling technique, and supporting CASE tool. After 


considering all of the factors, there was no one single BPR methodology that exactly fit 


the MCI situation at face value. Elements of each were used in the end and will be 


discussed in detail in Chapter VII. 
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The methodologies of Hammer and Champy, and Davenport were both ruled out 
as the business culture at MCI would not support sweeping changes to their current 
business process. Although Hammer and Champy do not offer specific techniques, their 
reengineering principles and ideals are crucial to successful reengineering. Davenport 
provided sound guidance at the strategic vision level, establishing a need for 
reengineering, and determining where in the organization to look, but lacked techniques 
for conducting the reengineering. 

In contrast, DoD’s functional process improvement provided too much detail. It is 
not necessary to conduct all of the FPI tasks to successfully accomplish organizational 
reengineering. FPI ws not selected due to the distinct lack of accurate cost data available 
at MCI necessary to drive the ABC cost models. 

The authors f2 t that Harrington’s business process improvement methodology, 
based on continuous process improvement and offering comprehensive and detailed 
techniques, provided the best fit for MCI modernization. Combining Harrington’s BPR 
methodology with Martin’s information engineering offers a strong overall methodology 
for analyzing MC] at the enterprise level. Additionally, the integrated philosophy espoused 
by information engineering offered more flexibility and potential for application to the 


remaining business processes at MCI not included as part of this research. 
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V. TECHNIQUES AND TOOLS 


This chapter discusses in greater detail some of the techniques and tools used 
during the analysis of previous chapters. The first section discusses process modeling, 
functional decomposition, and IDEFO modeling methodology. The second section 
discusses data flow diagramming and its relevance to the business system design level of 
the information engineering methodology. The final section discusses CASE tool 
evaluation and selection for the MCI modernization project. 


A. ACTIVITY MODELING 


There are many different modeling and diagramming techniques in use for process 
modeling. Techniques have been borrowed from finance, software or systems engineering, 
and product engineernig. Examples of modeling techniques include: entity-relationships 
(ER), structure charts, flow charts, data flow diagrams, and IDEF modeling. Many of the 
techniques are variations of one another and may share semantic structures but vary in 
their graphic presentation to convey different aspects of the organization to different 
audiences. For instance, a business may be modeled with an entity-relationship diagram for 
the database designer while the same business may be presented to the programmer as a 
series of data flow diagrams. Different views of the business require different modeling 
techniques. 


1. Process Modeling and BPR 


The main objective of business process reengineering is to transform an 
organization around the key processes performed by the business to improve productivity 


and efficiency. Since BPR was popularized in the early 1990s by Michael Hammer, many 
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similar but competing BPR methodologies have been published. Although they vary in 
scope and complexity, the common thread among them is the use models to represent the 
interdependent and often complex relationships that exist between the elements of a 
modern organization (1.e., business rules, processes, stakeholders, inputs and outputs). 
Effective BPR can not be conducted without first understanding the organization. Models 
enable understanding by structuring business information in a way that individual 
components can be visualized and interdependencies can be analyzed. 

Models are more than diagrams. While the diagram of a model may depict a 
process as a series of activities with inputs and outputs, many details about the process 
need to be defined. Information such as the activity’s name, definition, owner, inputs, 
outputs, etc. are stored in a central repository known as a data dictionary or data 
encyclopedia. The data contained in a data encyclopedia is also known as metadata. This 
collection of metadata ensures consistency throughout the modeling process. 


2. Process Modeling Technique 


A process or activity model is a tool used by an analyst to understand a business’ 
current environment and provides a framework with which a business may be 
systematically dissected and analyzed with an eye to improve the business process in some 
way. A process...1s a specific ordering of work activities across time and place, with a 
beginning , an end, and clearly identified inputs and outputs: a structure for action” 
(Davenport, 1993). These activities are the building blocks of process models. The 


process model makes business area analysis possible. 
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A completed process model graphically depicts the individual steps, information, 
and resources needed to perform a business process as well as how sub-processes may be 
interdependent. Additionally, activity modeling is an important step in validating 
information requirements within an organization, because the activity model shows the 
relationship between an activity and the information that it uses or produces. This level of 
detail is necessary to conduct effective redesign analysis. 

A process or activity model is used to describe business activities and their 
relationships. It is hierarchical and starts with a high-level view of the process. The model 
then breaks a process into sub-processes. Sub-processes may also be divided into sub-sub- 
processes and so on providing increasing levels of detail. This technique is known as 
functional decomposition. For this reason, individual activity model diagrams are often 
known as decomposition diagrams. Functional decomposition is further explained in the 
next subsection. 

The IDEF series of modeling methodologies offer easily interpreted diagrams, data 
sharing capabilities between data and process models, and a standardized format well 
Suited for computer aided analysis. IDEFO was mandated by MCI for process modeling, 
and IDEF1X was mandated for data modeling. IDEF modeling techniques are the 
modeling standard for agencies within the Department of Defense. 

IDEFO is one of the most useful process modeling techniques and was used for this 
analysis for two reasons. First, IDEFO is the modeling technique mandated by the 
Department of Defense (DoD) business process reengineering initiative, an agenda item of 


the Corporate Information Management (CIM) program. CIM was initiated in the early 


72 


1990s when Paul Strassmann was the director of the Defense Information Systems Agency 
(DISA). CIM’s goals were to maintain DoD mission capabilities despite downsizing and 
budget reductions by implementing improved business processes which: (1) are enabled 
by technology, (2) substantially increase productivity, (3) decrease cost, and (4) do not 
sacrifice quality. Secondly, the IDEFO modeling technique has unique and powerful 
features not found in any other single process modeling technique. Figure 7 is an example 


of a decomposition diagram using the IDEFO modeling technique. 
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Figure 7. LDEFO Activity Diagram. 
3. Functional Decomposition 


The process model is developed using a technique known as functional 


decomposition. Functional decomposition is a method of moving from the functional 
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areas at the enterprise level through the business areas and finally exploding the business 

processes to their primitive level. Figure 8 graphically depicts functional decomposition. 

The figure is useful in helping the reader to distinguish between several related terms. 
Functional areas are defined at the enterprise level and exist to define the business 


functions of the organization as a whole. Functional areas are the very essence of the 


Functional Areas 
of the Enterprise 


Business 


ma 


Business 


ee 
ic 
Functions 


Business Processes 
may be decomposed 
into lower-level 


DPrOCeESSe€S 
Figure 8. Functional Decomposition. After Martin, 1992. 
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business and refer to major areas of activity, but do not include sufficient granularity for a 
detailed analysis. For example, when developing the MCI enterprise model, seven 
functional areas were identified that represent the business activity of MCI (described in 
Chapter VI). These include headquarters support, course management, course 
development, student servicing, information systems management, warehouse and 
distribution, and unit interaction. These functional areas define the business of MCI but do 
not provide enough detail to describe the detailed processes performed by MCI personnel. 
Functional areas are subdivided into business functions. 

Business functions are a collection of activities which together support a functional 
area by furthering the mission of the organization. A business function is continuous and 
ongoing and is concerned with what is to be done but not how. For example, four business 
functions support the functional area student servicing, identified in the MCI enterprise 
business model. These business functions include customer servicing, student activity 
transactions, grading, and registrar servicing. Like the functional areas, these business 
functions lack sufficient detail for analysis. Business functions are subdivided into business 
processes. (Martin, 1990B) 

A business process is a specific act with a definable beginning and end, identifiable 
inputs and outputs, and is performed repeatedly. It is at this level that sufficient detail is 
added to the model to allow for analysis and reengineering. Complex processes may be 
further subdivided into simpler processes until a primitive level process 1s reached when 


any further decomposition would yield no greater understanding of the process. 
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Enterprise le. «1 modeling tends to emphasize the terms functional area, business 
function, and business process. Once the business area analysis stage begins, functional 
areas are known as business areas, business functions are known as functions, and business 
processes become processes. The terms are often used interchangeably in reengineering 
text books. The term activity is a generic term often substituted for a process at any level 
of analysis. The similarity of the terms can be confusing. Table 3 maps the term to the 


information engineering stages. 


Enterprise Analysis Business Area Analysis 
(Information Engineering (Information Engineering 
Stage 1) Stage 2) 


functional are2 of the enterprise 1s | business area 
known as 


business function of the enterprise is | function 
known as 


business process of the enterprise 1s | process 
known as 





Table 3. Terminology Map Between the First Two Levels of IE. 
4. Evaluation of IDEFO Technique 


IDEFO was developed in the late 1970s as a by-product of the U.S. Air te 
Integrated Computer Aided Manufacturing (ICAM) Program. The Integration Definition 
for Information Mod«.ting (IDEF for short) technique resulted in several graphical 
modeling conventioy.s. each used for a different purpose. For example, IDEF1X is used 
for data modeling anu [DEFO is used for functional modeling. Although IDEFO was 
orginally used to document manufacturing processes and to show what information and 


resources were needed in each step, it was proven to be well suited for modeling any 
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application that uses information and resources. IDEFO modeling has been used in both 
government and private industry since 1985 and has become the DoD standard for process 
modeling. 

An IDEFO model represents business activities from a functional point of view. 
The model depicts how the activities interrelate, the inputs used by each activity during 
activity execution, and the output of each activity. The model itself is hierarchically 
composed of decomposition diagrams and the data repository which contains the 
definitions of, and relationships between, each of the activities, inputs, outputs, controls, 
and mechanisms. The acronym ICOM is used collectively to describe any of the possible 
information flows into or out of an activity: inputs, controls, outputs, or mechanisms. 
The IDEFO activity modeling technique represents the business process with four types of 
diagrams in addition to the metadata encyclopedia. 


1. Node trees diagrams graphically portray activities in a hierarchical form. 
2. Acontext diagram is a single diagram that illustrates the highest level activity. 
3. Decomposition diagrams represent the detailed sub-processes of an activity. 
4. FEO (For Exposition Only) diagrams are used to focus attention on a 
particular portion of a node tree, context, or decomposition diagram and do 
not have tc conform to all of the modeling rules. 
IDEFO process models integrate smoothly with activity based costing techniques 
to provide a powerful all-encompassing model to accelerate the reengineering process. 
ABC is a powerful tool for measuring business performance, determining the business 


process costs, and as a means of identifying ineffective and inefficient activities. Because 


the IDEFO activity model provides a structured approach detailing an activity’s 
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information input and output, the addition of process cost details (e.g., the cost of labor, 
materials, and overhead) associated with accomplishing the task, the value of each 
individual task’s contribution to the whole can be assessed. Activities that are not cost 
effective, or add no value to the business product, but do incur costs, become early targets 
for elimination when streamlining the business process. 


5. IDEF0 Terminology and Constructs 


This section presents a brief overview of IDEFO terminology, symbols, and 
constructs to assist the reader in interpreting IDEFO diagrams. Figure 9 illustrates the 


IDEF symbols. 


Control 


Activity 


Mechanism Call 





Figure 9. IDEFO Symbols. 


Activity - a function or process that must be accomplished and produces output. 
Activities are represented by a box, are numbered hierarchically, and are named 
with a verb phrase to describe what they do. Activities are numbered hierarchically 
with each decomposition retaining the parent’s number followed by a decimal 
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point and its own number beginning with one. (e.g., the parent activity numbered 
A-1.2 could have two children numbered A-1.2.1 and A-1.2.2). 


Primitive Activity - an activity that is not decomposed further (1.e., has no children 
activities). In a decomposition diagram, a primitive level process is distinguished 
by a small diagonal slash, known as a leaf, in the top left corner of the activity box. 


Context Diagram - the model diagram representing the highest level activity or 
process. It contains only one activity box with the model subject as its name. It is 
the starting point for the decomposition of the entire model. The context diagram 
is numbered A-O. 


Decomposition - a method of moving from general to specific through 
decomposition diagrams by separating activities into components. 


Decomposition Diagram - a diagram representing a more detailed look at an 
activity. The top level provides overview while each succeeding diagram provides 
greater detail of the previous diagram. Decomposition diagrams are numbered 
hierarchically with each subsequent diagram retaining the parent’s number 
followed by a decimal point and its own number beginning with one. (e.g., the 
parent diagram numbered A2 would have a child diagram numbered A2.1) 


Parent Diagram - any decomposition diagram that contains an activity that has 
been decomposed (1.e., has children diagrams). 


Child Diagram - any decomposition diagram that represents the details of a parent 
activity. 


Node Tree Diagram - shows the activities arranged hierarchically in a tree 
structure. 


Input (Arrow) - represent data or objects consumed by the activity. Input arrows 
always enter the diagram from the left and terminate at an activity. 


Output (Arrou-) - represent data or objects produced by the activity. Output 
arrows always exit an activity and exit the diagram to the right. 


Control (Arrow) - represent data or objects that specify conditions that must exist 
for the activity to work correctly. Control arrows always enter the diagram from 
the top and terminate at an activity. 


Mechanism (Arrow) - represent data or objects that assist the activity in 
performing its task. Mechanism arrows always enter the diagram from the bottom 
and terminate at an activity. 
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Call (Arrow) - a type of control arrow that calls on another activity. Call arrows 
always exit an activity and exit the diagram at the bottom. 


B. DATA FLOW DIAGRAMS 


Data flow diagrams are another representation of the process model. Specifically, 
DFDs are used to depict the information system model. Once the process model has been 
reengineered, the business system designer must develop a prototype. Input and output 
information depicted on the activity model is too abstract to aid the programmer in 
prototype development and coding. A programmer must retrieve the data from the 
database tables, manipulate it according to the process model and business rules, and 
finally, route the output data to another process or database table. For this reason even the 
lowest level process decomposition diagram 1s of little use to the programmer because the 
process model does not indicate the precise source or destination of the data. A DFD 
maps the data sources and sinks (1.e., database tables) to the data elements that flow to 
and from each process. Data flow diagrams serve as the interface between the data 
modeler, process developer, and GUI/prototype designer. 

Data flow diagrams start at the highest level with a context process designated as 
the context diagram. Diagram level zero then decomposes the context diagram into major 
activities. Decomposition continues to a level that allows the programmer to map 
individual data elements to specific process activities. Figure 10 is an example of a 
primitive level DFD showing the information system designer which data elements are 


required and from which database table they originate. 
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Figure 10. Primitive Level Data Flow Diagram. 





1. Similarities Between DFDs and Activity Models 


Because activity models and data flow diagrams represent the same process and 
data elements, there aie similarities between them. Properties that process models and 
DFDs share include: functional decomposition, hierarchical numbering, and parent/child 
relationships. 

Functional Decomposition - The functional decomposition concept is the same. In 
DFDs a context diagram, numbered “O”’ forms the basis for the system and all 
decompositions stem from it. 

Hierarchical Numbering - The hierarchical numbering scheme for DFDs is similar 
to that used in the activity models. DFD process numbers are prefixed with a “P.”” DFD 


data store numbers are prefixed with a ““D.”” DFD processes are numbered hierarchically 
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with each decomposi-¢on retaining the parent’s number followed by a decimal point and its 
own number beginning with one (e.g., the parent process numbered P-1.2 could have two 
children numbered P-1.2.1 and P-1.2.2). Prmmitive level processes are denoted with a “P” 
pmtix, (¢.2., P-2,3.2.1P). 

Parent/Child Relationships - Child processes and data stores are considered to be 
part of their parent and serve to reveal more detail. For example, it is assumed that when 
referring to a parent data store all information contained in its children is included. 


2. Data Flow Diagram Symbols 


Although DFDs are a similar to the process decomposition diagrams of the As-Is 
and To-Be IDEFO models they use different notation. There are three data flow 
diagramming symbo} ~onventions in contemporary use: Gane and Sarson, Yourdon and 
DeMarco, and Ward and Mellor. Each depicts data flows within a information system 
using different symbology. Data flow diagrams for this project are created in the Gane and 
Sarson convention. DFDs depict only four symbols: (1) external entity, (2) process, (3) 
data flow, and (4) data store. Figure 11 depicts Gane and Sarson DFD symbols. All DFD 
objects are defined in the central data repository. 

External Entity/Source or Sink (not to be confused with entity in the data model 
terminology) - a data source from outside the information system that either sends data to 
the system or receives data from the system. It is not considered to be part of the 
information system a!tiough it interacts with the system. Outside entities are labeled with 
a noun. They may be duplicated on different diagrams and are depicted on the diagram as 


a double square box. 
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Process Status 
Request 


Data Store ere 
STUDENT 


Figure 11. Gane and Sarson Data Flow Diagram Symbols. 





Process - represents an activity that transfers or transforms data within the system. 

Processes are labeled with a verb-adjective-noun and numbered hierarchically. They may 
~ be duplicated on different diagrams and are depicted on the diagram as a box with 

rounded corners. The hierarchical process number is shown in the top portion of the box. 

Data Flow - data that is created, read, updated, or deleted by the system. 
Arrowheads denote the source and destination of each piece of data. Data flows are 
labeled with a noun. They may be duplicated on different diagrams and are depicted on the 
diagram as an arrow. 

Data Store - may represent a computerized file, a database, a manual store, or a 
logical collection of data. Temporary files created by processes within the system are not 


considered in the data flow diagrams. Data stores are labeled with a noun and numbered 
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hierarchically. They may be duplicated on different diagrams and are depicted on the 
diagram as a rectangle. 


3. Process Specifications 


Process specifications are a verbal description of the process. Process 
specifications accompany DFDs and provide a concise summary of each activity. They aid 
the prototype developer in interpreting the data flow diagrams. Examples of process 
specifications include: process name, process number, data inputs, data outputs, 
structured English description of the process logic. 


C. CASE TOOLS 


Information engineering is a flexible methodology supported by many generic 
software CASE tools. Initially, Texas Instruments developed a mainframe based CASE 
tool specifically supporting Martin’s planning, documentation, modeling, analysis, and 
reporting techniques. As information technology evolved from mainframes to networked 
PC architecture, a variety of generic BPR CASE tools supporting central data 
repositories, process ‘nodeling, data modeling, structured design, and code generation 
have been developed to support the methodology. IE methodology is comprehensive, 
covering all phases of system the life cycle. The reader will recall that the specific 
techniques used in the IE methodology are not specified and secondary to the integration 
and application of the underlying framework. This flexibility allows IE methodology to be 
tailored to achieve the best possible match of situation to technique. For example, a 


variety of process modeling techniques can be used such as IDEFO, entity-relationships, 
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Structure charts, or data flow diagrams. Each modeling methodology is used to show 
different views of the same process. 

Many CASE tools have been designed specifically to support business process 
reengineering, data, and process modeling. Choosing an appropriate CASE tool to assist 
the analyst early in the reengineering effort reduces the length of time to complete the 
project. 

1. Selection Criteria 


CASE tool selection should be done after a reengineering methodology is selected. 
Tool choice should be based on its ability to support all aspects of the reengineering 
methodology. If one tool will not satisfy all of the requirements, the ability for multiple 
tools to share data becomes an overridin g consideration. Careful scrutiny of the advertised 
data sharing proceduies and interfaces is also advised to enhance seamless integration 
between the tools. Regardless of the reengineering methodology chosen, a CASE tool 
should possess the fo'lowing capabilities. 

e Capture, visualize, and monitor end-to-end processes 

e Represent process rules and exceptions 

e Dynamically re-plan and reschedule activities 

e Simulate discrete events 

e Analyze the tradeoffs in hypothetical scenarios of process redesign 


e Proactively manage and learn from day-to-day events 
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2. CASE Tool Evaluation 


There are many CASE tools available to support business process reengineering. 
The authors initially considered four such tools: System Architect/BPR Professional, 
BPwin®, Informatior Engineering Facility™, and TurboBPR. 

Information Engineering Facility™ (IEF™) was developed with James Martin by 
Texas Instruments to support Martin’s information engineering methodology. Although, 
JEF™ offered the most comprehensive support package of the CASE tools, its use was 
rejected outright because both its own operation and the code it generated is based on 
mainframe technology. 

TurboBPR 2.5 is a Windows-based business process reengineering support tool 
developed for the Office of the Secretary of Defense by SRA Corporation. TurboBPR is 
designed specifically co support the DoD functional process improvement methodology. 
TurboBPR consists ot five modules to assist with enterprise level information storage, 
strategic planning, act.vity based cost accounting, and preparation of the functional 
economic analysis. In spite of a formidable reporting feature, TurboBPR 2.5 was not used 
for this research because it lacked integral data and process modeling modules. 

The remaining two competitors, System Architect/BPR Professional (SA/BPR 
Pro), by Popkin Software & Systems Incorporated, and BPwin® (BPwin), by Logic 
Works, Incorporated, are windows based modeling and simulation software designed to 
Support a variety of business process reengineering methodologies by documenting 
complex business provesses. Both CASE tools offer comparable performance and share 


common features: 
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e¢ Acommcr data repository, ensuring model consistency 


e Structured analysis & design techniques for creation of DFDs, STDs and 
structure charts in standard or real-time methodologies 


e Process modeling techniques including IDEFO 
e Object oriented design techniques 
e Forward and reverse engineering capabilities 


e Project documentation facility offering desktop publishing features used to 
create reports and analyze data stored in the central repository 


e Additional features such as common word processor interface, rules checks and 
balancing. import and export capabilities, etc. 


The major difference between SA/BPR Pro and BPwin is that SA/BPR Pro has 
data modeling capabiiity and can generate database schemata in a variety of popular 
databases. BPwin has no data modeling capability of its own. 

Both SA/BPR Pro and BPwin have excellent on-line tutorial support. BPwin’s 
tutorial was particularly relevant to this research because IDEFO modeling examples are 
used to ulustrate the tool’s features. An inherent disadvantage of SA/BPR Pro’s additional 
features is the required diversity of the on-line tutorial. Despite comprehensive coverage, 
the tutorial is more complex and leaves the user with a sense that BPwin is more intuitive 
and easier to operate. To fully exploit all of SA/BPR Pro’s many features, considerably 
more time must be devoted to learning to operate the tool. 

SA/BPR Pro nas a more versatile graphics package for developing data flow 
diagrams. BPwin’s structured analysis and design screen graphics package limits the user 
to a single 8.5 by 11 inch page, often resulting in cluttered diagrams. SA/BPR Pro allows 


diagramming on multiple pages. 
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An attractive characteristic of both SA/BPR Pro and BPwin is the advertised data 
sharing capability with the competition. In theory, this feature would permit parallel 
development of the data and process models using the premier CASE tool for each and 
allow maintenance of a virtual metadata encyclopedia. The choice of closely integrated 
tools that allow data models and process models to share data sounds appealing and was 
attempted. However, as parallel model development progressed, the authors discovered 
that in order to “share” data between models required exporting the data into Microsoft 
Word, converting the file into a comma delimited format, and finally importing it into the 
other model. As the nember of activities, arrows, relationships, entities, and attributes 
continued to grow, this import/export routine became quite cumbersome. Unfortunately, 
this procedure was necessary even for minor changes to maintain model consistency. 
SA/BPR Pro’s single data repository would have eliminated this inconvenience. 

A feature BPwin has that SA/BPR Pro does not have is an advertised compatibility 
with a sibling data modeling product, ERwin. ERwin was the CASE tool chosen for data 
model development. Their common manufacturer claimed seamless data sharing between 
the two products by building identical data structures within the encyclopedia of each ‘eal. 
However, as parallel rnodel development progressed, it was discovered that a similar 
import/export routin= was necessary to transfer data model information from ERwin into 
BPwin. This process 31d not require the exported file to be comma delimited before 
import, but the two data encyclopedia structures were not identical. Initially, definitions 
generated and stored by ERwin could not be imported into BPwin. In spite of this fault 


process model development was not impeded because data element and data table names 
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were imported and could be used. Deficiencies in the BPwin data dictionary were 
overcome by a softwere patch distributed by the vendor which enabled the data dictionary 
file of both tools to produce one encyclopedia containing all model information. 


3. CASE Toai Selection 
CASE tool selection for the MCI modernization project is based on supportability 
of the information engineering methodology and the IDEFO modeling technique. In spite 
of the fact that Texas Instruments’ Integrated Engineering Facility™ CASE tool was 
developed specifically to support the IE methodology, its mainframe theme made it 
unsuitable for MCI modemization use. TurboBPR2.5, too, was unsuitable because it did 
not support process modeling with an integrated module. CASE tool contenders were 
quickly narrowed to System Architect/BPR Professional and BPwin®. BPwin® was 
selected over to System Architect/BPR Professional for several reasons. 
e Advertised interoperability with its sibling data modeling product, ERwin®. 
ERwin® yas the CASE tool selected for the data modeling portion of the MCI 
modernizéuon project. 


e Intuitive functionality made BPwin® easier to learn than System 
Architect/BPR Professional. 


¢ Economically, the BPwin®/ERwin® combination was more affordable than 
System Architect/BPR Professional. 
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VI. MCI ENTERPRISE ANALYSIS 


This chapter describes the process modeling effort in support of the MCI 
modernization project. The chapter begins with a detailed description of the enterpnse 
analysis. It includes a survey of the data collected with an explanation of its analysis. The 
chapter concludes with the presentation of the enterprise business model. 


A. ENTERPRISE ANALYSIS OVERVIEW 


An enterprise analysis provides a high-level overview of the information 
requirements of an organization. The objective of this effort defines an architectural 
framework for future development. The framework consists of three major components: 
information, business system and technical architecture. The three architectures lay the 
foundation from which the organization can build an information system to manage its 
information resources and support its business activity. (Martin, 1990B) 

A high-level perspective provides a basis from which detailed analysis in 
subsequent stages can be pursued. It serves as a mechanism to identify interdependency 
and redundancy of business activities within the organization. The first stage of Martin’s 
IE methodology provides a technique to identify, evaluate, plan and manage the use of 
information to meet the organization’s information system requirements. 


B. MCI ENTERPRISE ANALYSIS 


The enterprise analysis conducted for MCI was accomplished in two parts. The 
first part identified the organizational units, locations, functions and data subjects for MCI. 
This was a data collection effort directed at defining the architectural framework of 


development of MCI’s information system. The second part focused on analyzing the data 
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collected to document an enterprise overview of MCI. The documentation analyzes the 
relationships between organizational units, locations, functions and data subjects, as 


illustrated in Figure 12, using charts and matrices. 


ORGANIZATIONAL 
UNIT 





Figure 12. Enterprise Analysis Components. 
After Martin, 1990B. 


C. IDENTIFY INFORMATION SYSTEM REQUIREMENTS 


The NPS team traveled to the Marine Corps Institute in Washington, DC for the 
MCI Redesign kick-off meeting held August 26-29, 1996. Prior to the meeting, the NPS 
team received a read-ahead package from MCI. The package included a description of the 
existing organizational structure, an incomplete business model previously prepared by an 
independent contractor, an existing data dictionary, a task breakdown of Student Services 
Department, historical bnefing packages and background documentation on Marine Corps 
Institute. Each department head presented a brief that identified the department’s 
organization, key personnel, mission and functions. The meeting provided a means to 


observe the business culture and political environment of MCI. Additional documentation, 


98 


such as training manuals, SOPs, existing input screen shots, and management reports, was 
obtained during interviews and in response to requests following the initial meeting. 

MCIAIS is a mission-critical system to MCI. The Student Services Department is 
the chief beneficiary of the information stored within MCIAIS. This is primarily due to the 
lost functionality of various sub-systems over time. It was apparent that each department 
head was frustrated because the current MCIAIS was driving the way they did business, 
instead of enabling improvements to process efficiency. 


1. Organization Structure 


Chapter If described the organizational structure into which MCI fits. The 
enterprise analysis focuses on MCI’s reporting structure. An understanding of the MCI in 
this context was important to identify stakeholders to interview and provided a basis for 
determining responsibilities for the activities of the enterprise (Martin, 1990B). 

The Director of Marine Corps Institute is also the Commanding Officer of Marine 
Barracks, Washington, DC. This billet is staffed by a Marine Corps Colonel. The position 
as Commanding Officer carries the responsibility for the activities of the Marine Barracks 
companies, one of which 1s the MCI Company. (MCI In-Bnief, 1996) 

The Deputy L:rector is accountable to the Director of MCI. This billet is staffed by 
a Marine Corps Lieutenant Colonel. This position is responsible for the performance of 
MCI Company in executing the seven MCI mission tasks identified in Chapter II. (MCI 
In-Brief, 1996) 

MCI Company is composed of six departments: Headquarters Department, 


Professional Military Education Department, Occupational Skills Department, Logistics 
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Department, Student Services Department and Management Information Systems 
Department. The authors also considered Marine Corps unit’s Training Departments to be 
a department because of its functions in the administration of student records. (MCI In- 
Brief, 1996) 

The Headquarters Department is composed of four sections: Administration 
Section, Operations and Training Section, Edit Division and Performance Improvement 
Requirements (PIR)Section. Headquarters Department exercises staff cognizance over the 
MCT's departments for the production and support of distance education and training 
materials. (MCI In-Brief, 1996) 

The Professional Military Education Department (PMED) consists of six divisions: 
Command and Staff College Nonresident Program Division, Amphibious Warfare School 
Nonresident Program Division, Warfighting Skills Nonresident Program Division, 
Sergeants Nonresident Program, Staff Non-Commissioned Officer (SNCO) Career 
Nonresident Program and Staff Non-Commissioned Officer (SNCO) Advanced 
Nonresident Program Division. PMED provides distance education that is a prerequisite 
for, or parallels, Mar 22 Corps resident school curricula. (MCI In-Bnief, 1996) 

The Occupational Skills Department (OSD) is comprised of seven divisions: 
Command and Control Division, Combat Operations Division, Combat Support Division, 
Combat Service Support (CSS) Operations Division, Administration/Finance Division, Job 
Aids Division, and Graphics/Layout Division. OSD develops and maintains nonresident 


courseware and military occupational specialty (MOS) specific job aids, to include the 
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Marine Battle Skills Training and the Battle Drill Guide for use by the active and reserve 
components of the Marine Corps.(MCI In-Brief, 1996) 

The Logistics Department is comprised of six divisions: Stock Control Division, 
Demands/Fiscal Division, Property Control/Support Division, Warehousing Division, 
Postal Division, and Reproduction Division. Logistics Department procures, stocks, 
packages, and distributes courses and training products, produces and manages the fiscal 
plan, provides postal services, organizational supply, logistical support, printing and 
reproduction services to MCI and Marine Barracks. (MCI In-Brief, 1996) 

The Student Services Department (SSD) is comprised of five sections: Immediate 
Assist Section, Enrollment Section, Grading Section, Unit Activity Report (UAR) Section, 
and Registrar Section. SSD is responsible for the enrollment, grading, and management of 
student records for MCI’s distance education and training programs. (MCI In-Brief, 1996) 

The Manager.ient Information Systems Department (MISD) 1s comprised of two 
sections: Information System Management (ISM) Section and Programming Section. 
MISD provides information systems support to the Marine Barracks and to MCI in the 
enrollment, grading, and management of student records. (MCI In-Bnief, 1996) 

The Marine Corps unit Training Department is normally one person, the unit 
Training NCO. The Training NCO is a MCI representative within the Marine Corps unit, 
in much the same way as Lieutenant Colonel Harllee set up when correspondence courses 


were first offered 77 years ago. 
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2. Business Locations 


The physical location of each organizational unit is important to the development 
of technical architecture. It provides a basis for determining the physical attributes the 
information system must satisfy for the business activities of the enterprise. (Martin, 
1990B) 

A tour of MCI during the initial brief revealed the location of the MCI offices and 
work spaces where the various business activities take place. The office for Director of 
MCI is located at the Marine Barracks, 8" and I streets. This is approximately six blocks 
from the MCI buildings. The office for the Deputy Director is located on the second floor 
in building 220, Lejeune Hall, at the Washington Navy Yard. MCI Headquarters 
Administrative and PIR sections, PMED, SSD and MISD are also located on the second 
floor of Leyeune Hall. OSD, Operations and Training section, and the Edit Division are 
located on the first fleor of Lejeune Hall. The Logistics Department is located, across the 
street from the rest of MCI, in building 169 of the Washington Navy Yard. The Marine 
Corps unit’s Training Department is located in literally hundreds of operating locations 
around the world. 


3. Business Functions 


The enterprise business functions were decomposed from seven high-level 
functional areas. Functional areas refer to the major business activities and serve as the 
Starting point for further decomposition in the subsequent Business Area Analysis. The 
functional decompos'tion of MCI’s enterprise activities is illustrated in Figure 13. 


e Headquarters Support - The functions that provide planning, parade support 
and perso-inel administration for MCI. 
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e Course Development - The functions that support the design, writing, revising, 
staffing, and production of MCI courses, programs, and job aids. 


e Course Management - The functions that support the advertising, budgeting, 
training and analysis of MCI courses, programs, and job aids. 


e Student Services - The functions that support data entry for student record 
management, student servicing, grading, and course completion certification. 


e Information System Management - The functions that support the network 
management, programming and database administration for MCI. 


e Warehouse and Distribution - The functions that support purchase, receipt, 
storage, inventory, packaging, distribution and disposal of MCI courses, 
programs, and job aids. 


e Unit Interaction - The functions performed by the Marine Corps unit training 
departments in support of the administration of MCI courses, programs, and 
job aids. 


MCI Enterprise Level 
Functional Area Decomposition 
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Figure 12. MCI Enterprise Level Functional Area Decomposition. 
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A business function is a collection of related activities which completely support 
one aspect of furthering the enterprise’s mission (Martin, 1990B). Figure 14 provides an 
overview of many functions performed by the various organizational units in the 
development, distribution and management of the distance training and education courses 
and programs. The functions represented in the flowchart were used to generate an initial 
candidate list of business functions performed by the MCI enterprise. The business 


function candidate list was revised several times as each organizational unit was analyzed. 
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Figure 14. Product Development, Distribution, and Management Flowchart. 


Business functions were then defined. Defining the business functions is important 
to understanding the business process as a whole. However, at the enterprise level, 


business function definitions are independent of the organizational structure (Martin, 
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1990B). The definitions were not linked directly to an MCI organizational unit or its 
location because the reporting structure may change but the functions still must be 
performed. A total of 33 candidate business functions were identified and defined during 
the enterprise analysis. 


e Advertising - To publish or announce the availability of Programs, Courses 
and Job Aids in the MCI Course Catalog, military newspapers, ALMARs, 
MARINE magazine, etc. 


e Analysis Of Effectiveness - To collect data from returned exams and student 
feedback sheets, and analyze data in order to revise exam questions or 
Program and Course text. 


e Budgeting - To manage budget categories for developing, producing and 
distributing MCI Programs, Courses and Job Aids. 


e Course Design - To identify and establish the design specifications, schedule 
and prerequisites for MOS Courses and Job Aids to meet Marine Corps 
training and education requirements for target audience. 


e Course Revising - To revise Job Aids and MOS Course text, examinations and 
related material based on feedback from students, Course sponsors, CG, 
MCCDC aad internal analysis of effectiveness. 


e Course Staffing - To allow newly designed MOS Courses and Job Aids to be 
reviewed by all of the agencies and departments responsible for its production 
and distribution. 


e Course Wniting - To research and write the MOS Course text, components, 
examinations and Job Aids. 


e Customer Servicing - To respond to customer inquiries of any nature (as it 
relates to the MCIAIS) and process customer requests for MCI action 
(enrollment, material request, update information, etc.). This service supports 
inquiries received by telephone, electronic mail, U.S. Mail, or over the counter. 


e Database Administration - To download and upload TFS and unit diary 
informatic-n into the MCIAIS; to upload and service the automated telephone 
Conversant system database. To commit daily transaction files; to troubleshoot 
database or related problems; to backup database. 
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Delivering - To deliver Program materials, Course materials, Job Aids, 
Diplomas, Course Completions certification and course components to 
Students. 


Disposing - To purge obsolete Program and Course materials, Job Aids and 
course components. 


Editing - fo review new and revised Programs, Courses and Job Aids for 
Instructional System content and quality. 


Exam Proctoring - Monitoring examinations to Marines in the fleet to ensure 
compliance with the MCI Procedures Manual. 


Grading - To record the scores of examinations, in the MCI student database, 
graded by both automated & manually means. 


Inventory - To manage on-hand quantities and locations of on-hand material. 


Layout & Graphics - To create new graphics, improve existing graphics, and 
maintain library of appropriate graphics and artwork for Program text, Course 
text, and Job Aids. 


Manage Networks - To install, manage and maintain telephone and data 
network equipment. 


Ordering - To requisition Program and Course materials, Job Aids and course 
componer.ts distributed by MCI. 


Packaging - To assemble and shrink wrap Program and Course materials, Job 
Aids and course components for distribution and storage. 


Parade Support - To coordinate MCI personnel to support the ceremonial 
activities at the Marine Barracks. 


Planning - To schedule and coordinate all planning associated with MCI 
Parades and Ceremonial Details involving MCI personnel. 


Program Design - To identify and establish the design specifications, schedule 
and prerequisites for PME courses to meet Marine Corps training and 
education requirements for target audience. 


Program Revising - To revise PME Program text, examination and related 
material subject to feedback from students, Program sponsors, CG, MCCDC, 
and internal analysis of effectiveness. 
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e Program Staffing - To allow a newly designed or revised PME Program 
content to be reviewed by all of the agencies and departments responsible for 
its production and distribution. 


e Program Writing - To research and write the PME Program text, components 
and examinations. 


e Programming - To write program source code that corrects or enhances 
database administration. 


e Receiving - To receipt for materials that will be stored in the warehouse. 


e Registrar Servicing - To research and produce diplomas, completion 
certificates and transcripts for students. 


e Reproduction Servicing - To prepare negatives, camera-ready originals, and 
print specifications for contract orders to commercial printers, maintain 
negatives and camera-ready copy for MCI courses; to reproduce/print original 
documents for MCI or Marine Barracks in quantities less than 25,000. 


e Storing - To stock received materials. 


e Student Activity Transactions - To manage student records and monitor the 
transaction processing system. 


e Training - To coordinate training of MCI course wnters and programmers. 


e Unit Reconciling - To provide MCI with feedback from units so MCIAIS can 
be validated and updated if required. 


4. Data Subjects 


Data subjects refer to a higher level grouping of data entities. A candidate list of 
data subjects, provided in Table 4, was developed by the NPS team data modeler. The 
candidate list of data subjects, their definitions, attributes and relationships are detailed in 
the Analysis, Design, and Prototype Implementation of a Contemporary Information 
System for the Marine Corps Institute, Preliminary Report, (Kamel et al., 1997). The data 


subjects were decomposed in the subsequent Business Area Analysis. 
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Job Aid Information 
Job Aid Copy Material Information 
MCI Personnel Information 
MCTFES Personnel Information 
Order Information 

Program Information 

Program Copy Material Information 
Program Developers Information 
Purchase Information 

SSD Personnel Information 

Student Information 
Training Information 
Warehouse Information 


Table 4. Candidate List of Data Subjects. 














D. DOCUMENT THE ENTERPRISE 


The second part of the ISP stage documents the information requirements, 
identified during the first part. Graphic representations helped to summarize the collected 
data. The enterprise analysis of MCI was documented with an organization chart and 
several planning matrices which illustrate the relationships of MCI’s organizational units, 
locations, business functions and data subjects. 


1. Document Current MCI Organization 


The reporting structure of MCI Company was documented using an organizational 
chart. The organization chart, Figure 15, illustrates the hierarchical structure common 
among traditional military organizations. The sections are logically arranged to report to 
the respective departments. The dashed lines represent indirect operational support. In one 
case, the MCI Company provides parade and logistical services to the Marine Barracks 
operations. In the other case, Marine Corps units provide enrollment processing and 


reconciliation services necessary for MCI distance training operations. 
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Figure 15. MCI Company Organization Chart. 





2. Document Current Locations, Functions, and Data Subjects 


The relationships between the organizational units, locations, functions and data 
subjects define the architectural framework of the enterprise. A common technique used to 
document and analyze such relationships is to develop a series of planning matrices that 
cross reference and validate the various elements of the organization. Eight matrices were 
used to define the infcrmation and business system architecture for the MCI enterprise 
analysis: Organizational Unit versus Location, Function versus Organizational Unit, 
Function versus Location, Data Subject versus Organizational Unit, Data Subject versus 
Location, Data Subject versus Function (CRUD Matrix), Function versus Data Subject 
(CR Matrix) and Function versus Data Subject (Clustered CR Matrix). 

The Organizational Unit versus Location matrix, provided as Figure 16, 
summarizes the MCI organizational units and the locations where their business activity 


takes place. The matrix validated the organizational units with their locations. This 
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Figure 16. Organizational Unit versus Location Matrix. 


validation ensured all organizational units were accounted for in the analysis. Their 
locations would be considered in the technical architecture development. The “@’’marks in 
the same columns depict organizational units which operate from the same location. The 
marks in the same rows indicate organizational units which operate in different locations. 
The Function versus Organizational Unit Matrix, provided as Figure 17, 
summarizes the functions performed by each MCI organizational unit. The Function 
versus Location, provided as Figure 18, summarizes the locations in which the functions 
are performed. These .wo matrices validated the functional decomposition by ensuring 
that every function wes mapped to an organizational unit and that every organizational 
unit was involved in an identified function. The matrices also show the extent to which 


departments share data and perform redundant functions. 
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Figure 2 Function versus Organizational Unit Matrix. 


Two other matrices were produced by the NPS data modeler to illustrate the 


relationship between the data subjects with the organizational units and the locations. 
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Figure 18. Function versus Location Matrix. 





Together, these five matrices served to cross reference and validate the candidate data 
subjects and business functions and improved the project team’s understanding of MCI’s 
current strategy for conducting business. 

The relationship between business functions and the data subjects revealed the 


Information Architecture. Three matrices were used to group business functions and data 


subjects into natural business systems and natural data stores. These groupings identify the 
division of business areas in preparation for further detailed analysis. 

Each function was evaluated to determine if it would create, read, update, delete, 
or archive the corresponding data subject. A “C’, “R’’, “U”, “D” and/or “A”’ was placed in 
the row-column representing that data subject and function analyzed. Collating each 
combination produced the Data Subject versus Function CRUD Matrix given as Figure 
19. 

A CR Matrix, provided as Figure 20, was used as an intermediate step to generate 
the groupings necessary to identify the business areas. A ““C” was substituted for every 
“C’, “U", “D” or “A”. The columns and rows of the CR Matrix were arranged to create 
clusters of related fieions that create, update, delete and archive associated data 
subjects. The resulting Clustered CR Matrix revealed natural groupings that verify the 
natural division of sub-systems in preparation for the Business System Design stage. 


3. MCI’s Current Business Model 


The Clustered CR Matrix, provided as Figure 21, revealed eight business sub- 
systems that directly influence the MCI information requirements: Personnel 
Administration, Ceremonial, Program and Course Development, Program and Course 
Management, Student Service Support, Information System Management, Warehouse and 
Distribution, and Unit Interaction. 

The Clustered CR Matrix revealed two details worthy of discussion. First, the 
Personnel Administration and Ceremonial sub-systems influence business activity of MCI 


but actually have no direct interface with MCIAIS. Second, the Unit Interaction sub- 
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Figure 19. Data Subject versus Function (CRUD) Matrix. 
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Figure 19. Data Subject versus Function (CRUD) Matrix continued. 
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Figure 21. Clustered CR Matrix. 
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system uses data produced by MCIAIS and generates data input through MISD, but does 
not actually create or read a data subject directly. These three sub-systems were left in the 
matrix to give a complete representation of the business system architecture to consider 
during the reengineering phase. 

The MCI Preliminary Business Model, Figure 22, represents the division of the 
enterprise into lowe1 -vel business areas and functions. Subsequent analysis of each 
business area can be rerformed independently based on priorities determined during this 
initial evaluation to s “isfy the organizational requirements. MCI management determined 
the business activities of Student Service Support should receive the highest priority based 
on the information requirements and its role in the MCIAIS-IJ implementation plan. 

The boundaries of the business area analysis for Student Service Support adds 


definition to the MC! Modernization Project scope. The analysis did not focus on how the 
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Figure 22. MCI Preliminary Business Model. 
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database was populated, but on the data with which it would be populated, the SSD 
processes that use the data, and the interaction between the two. The key business areas, 
functions, and data si:bjects, identified during the MCI enterprise analysis, are illustrated 
with Figure 23. The business areas are represented by large rounded boxes. The functions 
are represented are cc-r.tained within the respective business area. External entities are 
represented with rectangles. The arrows represent interaction. The dashed line represents 
the boundary, and focus of the BAA. Migration of the legacy system’s functionality 
required identification of the data entities encountered with each interaction. The As-Is 


process model was developed to identify those details. 
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VII. MCI BUSINESS AREA ANALYSIS 


This chapter further describes the process modeling effort in support of the MCI 


modernization projec . The chapter begins with a detailed description of the Business Area 


Analysis and the subsequent development of the As Is Model for the Student Services 


Support business are. The detailed description of the tailored application of Business 


Process Reengineering follows. The chapter concludes with the presentation of To Be 


Process and Information System Models for the Student Services Department. 


A. BUSINESS AREA ANALYSIS OVERVIEW 


The Business Area Analysis (BAA) is the second stage of Information 


Engineering. The BAA is a refinement to a specific subset of the enterprise analysis. There 


are six objectives of a BAA project (IEF Guide, 1990): 


ir 


2: 


To fully identify and define the type of data required 


To idenufy and define the business activities that make up each business 
function 


To define the data required for each business activity 
To identity the necessary sequence of business activities 
To define how business activities affect the data 


To produce a plan for Business System Design (BSD) within a prioritized 
sequence of business systems. Normally, several business systems will be 
defined to support a single business area. 


The ultimate goal is to refine the business areas identified during the enterprise 


analysis. The ISP stage targeted the Student Service Support as the first business area for 


detailed analysis. Boundaries were established to identify the resources required to support 


development of a nev information system that will, at least, maintain the same 


VA 


functionality provided by the current MCIAIS in a new relational database. The detailed 
analysis focused on definition and refinement of the business activities performed by SSD, 
the objects that generate the activity, and the interaction between them. 


B. MCI BUSINESS AREA ANALYSIS 


The BAA for Student Service Support is built upon the information gathered 
during the ISP stage. Having already identified the functional areas and the business area 
to analyze, the NPS team initiated development of the As-Is Process Model. A detailed 
functional decomposition of the Student Service Support business area was done. The As- 
Is process model was presented as node tree and process decomposition diagrams and 
circulated for review. Business Process Reengineering techniques were applied. A To-Be 
process model was developed using IDEFO modeling technique. The proposed To-Be 
Process Model was circulated again for review. The refined model was validated using 
matrices and clustering as performed during the ISP stage. Once validated, an information 
system model was de eloped using data flow diagrams. The products of this analysis 
provided the necessary; information to develop a system architecture plan, a To-Be Data 
model, a To-Be Proc .s model, an information system model, and a prototype that 
validated the methodology. 


1. SSD BAA Implementation 


The As-Is process model represents the business activity of the Student Services 
Department in August 1996. Model development began with functional decomposition. 
The student service support business area was decomposed eight levels into 499 activities. 


A process decomposition diagram and node tree diagrams were developed to document 
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the analysis. This tec:inique provided sufficient detail to obtain a thorough understanding 
of SSD business. 

The process decomposition and node tree diagrams were developed with the 
BPWin® CASE tool. BPWin® was useful for the development of the metadata 
encyclopedia. It proved to be very simple to use and, after receiving a software patch, 
integrated well with its sibling data modeling CASE tool, ERWin®. 

A complete IDEFO model was not produced for the As-Is processes. The authors 
felt that too much time would be spent developing naming conventions for activities, 
relationships and entiiies of the non-relational database, which would detract from the 
reengineering effort. dowever, the activities that were likely to apply in the To-Be process 
model were defined u.d then refined when applied. 

During the reengineering phase it became apparent that an As-Is process should 
also include selected processes from other functional areas. Sufficient information had 
been obtained during the ISP stage to create high-level As-Is process models for other 
business areas: Course and Program Management, Course and Program Development, 
Warehouse and Distribution, and Information System Management. 

These decomposition diagrams were useful in the data model development. The 
enterprise level CRU matrix revealed a significant amount of data retrieved by SSD but 
owned by other business areas. Course or program information, stock status, MCTFS 
information are just o :}ew examples. The data model needed to reflect those data subjects 


for MCIAIS-II to retain the same functionality. 
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2. As-Is Model Details 


All of the activities depicted in the SSD process model are prefixed with “SSD” to 
distinguish it from models developed for other areas. Since the SSD As-Is process model 
is too large to print as a single document, it was broken into modules for readability. Only 
selected material will be presented to illustrate specific points. The model is provided in its 
entirety as Appendix B. 

The number of activities clearly demonstrates the level of detail pursued in the 
BAA of Student Services. This detail provided the NPS team with a thorough 
understanding of SSD activity. Additional model details must be gleaned from careful 
study of the process decomposition diagram or the node tree diagrams included as exhibits 
to Appendix B of the Analysis, Design, and Prototype Implementation of a Contemporary 
Information System for the Marine Corps Institute, Final Report, (Kamel et al.,1997). 


a. Functional Decomposition 


The b-isiness area of Provide Student Support was decomposed eight levels 
down to the primitive processes - a total of 499 activities. The first level identified six 
functions: OBTAIN CUSTOMER INPUT, MAKE CHANGES TO STUDENT’S 
COURSE ACTIVITY RECORD, GRADE STUDENTS EXAMINATIONS, PROCESS 
UNIT ACTIVITY REPORTS, PROCESS REQUESTS FOR MATERIAL, and 
PROCESS REQUEST FOR REGISTRAR ACTION. Figure B-1, Appendix B is a node 
tree diagram of the top three levels. 

The OBTAIN CUSTOMER INPUT- SSD1 function was decomposed into 


four processes: PROCESS INCOMING PHONE CALLS, SORT INCOMING U.S. MAIL, 
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SORT INCOMING ELECTRONIC MAIL, and PROCESS WALK-IN CUSTOMERS. This 
function represents the front end of customer service by receiving and replying to 
customer requests. One other method of customer processing is through the Marine Corps 
Unit Diary System. This method however is a process performed within the Information 
System Management business area and requires no Student services interface. 

The MAKE CHANGES TO STUDENT’S COURSE ACTIVITY 
RECORD - SSD2 function was decomposed into four processes: PROCESS REQUEST 
FOR ENROLLMENT, PROCESS CHANGE TO STUDENT INFORMATION, PROCESS 
REQUEST FOR ADMINISTRATIVE ACTION, and PROCESS STANDARD REQUEST 
FOR MATERIAL. This function represents most of the user interface with MCIAIS. This 
activity 1s replicated as sub-processes below OBTAIN CUSTOMER INPUT. In 
developing the As-Is model, the authors intended to use the replicated processes to model 
the different modes of access to MCI as a target for reengineering. 

The GRADE STUDENTS EXAMS - SSD3 function was decomposed into 
four processes: PROCESS PRE-SLUGGED DP-37s, PROCESS GENERIC DP-37s, 
PROCESS OPSCAN FRROR LISTING REPORT, and PROCESS HAND GRADED 
EXAMS. This function represents processing student lessons and examinations and 
products resulting form the activity. 

The PROCESS UNIT ACTIVITY REPORTS - SSD4 function was 
decomposed into two processes: WORK RETURNED UARs and PROCESS OUTGOING 
UARs BY US MAIL. This function represents the reconciliation processes between MCI 


and the Marine Corps unit Training NCO. 


2) 


The PROCESS REQUEST FOR MATERIAL - SSD5 function was 
decomposed into four processes: SEGREGATE REQUEST FOR REGISTRAR ACTION, 
SEGREGATE STANDARD REQUESTS FOR MATERIAL, PROCESS “REQUEST FOR 
MATERIAL” FORMS, and SEGREGATE “OFF-LINE REQUEST” FORMS. This 
function represents the processes to satisfy customer requests for new or replacement 
materials. Many of these activities are replicated as lower level sub-processes in SSD1. 

The PROCESS REQUESTS FOR REGISTRAR ACTION - SSD6 
function was decomposed into two processes: ISSUE (REISSUE) DIPLOMA and 
PROCESS TRANSCRIPT REQUEST. This function represents the activities of issuing 
diplomas and transcripts. 


b. Deéailed Analysis 


The detailed analysis was done by reviewing each provided SSD task 
breakdown sheet and modeling the activities described. Additional details were obtained 
from the MISD’s Standard Operating Procedures manual, the Marine Corps Institute 
Procedures Manual, telephone interviews, and replies to our specific requests. 

Model development revealed a significant number of manual activities. This 
drew a lot of attention because the manual processes seemed to cause a bottleneck to 
production flow. Modeling manual activities effectively during the As-Is effort sumplified 
the subsequent reengineering effort. 

OBTAIN CUSTOMER INPUT, activity number SSD1, models the 
process of receiving customer input. Figure B-2, Appendix B is a node tree diagram which 


illustrates four levels of that function’s decomposition. The figure depicts the flexibility 
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MCI applies to servicing customers by receiving their input in various forms: telephone, 
walk-in, electronic mail, and U.S. Mail. The model also demonstrates a relatively standard 
method of handling the input. Telephone and walk-in customers receive immediate 
attention while all other input is sorted and segregated for assembly line processing. 

U.S. niail processed by the Student Services Department is opened and the 
contents manually segregated for subsequent distribution. MCI administrative procedures 
specify that enrollment requests are submitted with an MCI Enrollment Application Card 
(R-1 Card). Other requests are submitted with a Student Request/Inquiry Form (R-11 
Card). Lessons and examinations are submitted on two different sized forms of an optical 
character recognition (OCR) capable form (DP-37). One form was pre-formatted with 
student and course information and distributed with the course materials when enrolled. 
The other is a generic form which the student completes when the examination is returned 
for evaluation. Course materials are distributed with a feedback form which is submitted 
when a lesson or exaiti is completed. Many of the Non-Resident Program examinations are 
essay type and not OCR capable. All requests for transcripts must also be written. 
Consequently, there is a single point of entry to process customer input by U.S. Mail. 

Electronic mail addressed to MCI is received in one electronic, 
organization mailbox (OMB), unless addressed to an individual. Electronic mail 
processing has not been standardized except for electronic Unit Activity Reports. 
Regardless of the subject matter, all electronic mail received in the OMB is printed, 


segregated and distributed for subsequent processing. The content of electronic messages 
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cover the same vaniet, of input as U.S. mail minus lesson and course examinations, 
without the convenience of a standard format. 

A student or Marine Corps unit representative, 1.e., Training NCO, First 
Sergeant, section non-commissioned officer in charge, can obtain course status through an 
MCI automated voice recognition system (AVRS) called Conversant. The caller contacts 
MCI’s toll free number, inputs the student’s social security number and course number, 
and Conversant returns the student’ course status. Conversant accesses a copy of the MCI 
student database resident on a remote server. 

MAKE CHANGES TO STUDENT’S COURSE ACTIVITY RECORD, 
activity number SSD, models the processing transactions that effect a student’s record 
within MCIAIS. Figure B-3, Appendix B is a node tree diagram which illustrates four 
levels of that function’s decomposition. Once an enrollment, inquiry, or other request is 
received, segregated and distributed, processing is the same as would be administered for 
a telephone or walk-in customer. The same screens are used to access data from MCIAIS 
in the same sequence regardless of customer entry mode. Transaction codes are entered by 
the user to reflect input that changed student activity records. A list of transaction codes 
are maintained near each user terminal. One interface characteristic identified user-entered 
data is not carried for ward when transitioning between screens. This required multiple 
entries of the same information and increased the likelihood of user error. 

GRAISE STUDENTS EXAMS, activity number $SD3, models the 
processing of lessons and examinations received from students and the output generated. 


Figure B-4, Appendix B is a node tree diagram which illustrates four levels of that 
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function’s decomposition. Two types of DP-37s are processed: pre-slugged DP-37s 
which are formatted prior to distribution course material issue, and generic DP-37s which 
are not. The DP-37s contain the same information but are different sizes. They must be 
segregated prior to processing. The DP-37s are scanned by an OCR reader, Scantron, and 
the data is collected 1:3 a file on a disk. The DP-37s successfully read are placed in a 
pending file. Those not read must be hand graded. DP-37s failed scanning because of form 
damage or key fields weren’t completed. The disk is delivered to MISD for batch 
processing during the nightly cycle. 

The OPSCAN Error Report, a list of all lessons and exams not processed 
by MCIAIS, is produced after the cycle is run. The DP-37s on that list must be pulled 
from the pending file and manually processed according to the error code. The remaining 
scanned DP-37s are moved to a completed file. The generic DP-37 increased the 
likelihood of incomp?zte forms, forms completed incorrectly, and forms received from 
individuals who hadz’: been enrolled. The generic form was created to simplify course 
material packaging ai. reduce distribution delays. 

Hand graded examination and PME examination scores are entered into 
MCIAIS manually. Corrected DP-37s from the OPSCAN Error Report are either 
processed through the Scantron again or entered into MCIAIS manually. 

PROCESS UNIT ACTIVITY REPORTS, activity number SSD4, models 
the process of reconciling MCIAIS student record activity with the records maintained by 
the Marine Corps unit. Figure B-5, Appendix B is a node tree diagram which illustrates 


four levels of that function’s decomposition. Unit Activity Reports (UARs) are generated 
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during a mid-month and monthly cycle batch process by MISD. UARs are produced in 
electronic form only during the mid-month cycle and both electronic and paper form at the 
end of the month. The unit must request, reconcile and return electronic UARs following 
procedures set forth zi: the Marine Corps Institute Procedures Manual. Procedures for unit 
reconciling UARs are the same regardless of the method of distribution. The unit reports 
the differences with annotations to the UAR and returns it to MCI. MCI processes the 
changes following the same procedures. Each annotation associated with a student record 
requires that record to be viewed on a terminal screen and checked to see if that record 
reflects the remark. If not, the change is entered following the same procedures as 
described during activity SSD2 - MAKE CHANGES TO STUDENT’S COURSE 
ACTIVITY RECORD. There is no action required by Student Services to process 
outgoing electronic LARs. The UARs that are produced in paper form must be packaged, 
addressed and mailed ¢o units not on electronic distribution. 

PROCESS REQUEST FOR MATERIAL, activity number SSD5, models 
the process of responding to customer and student requests for material. Figure B-6, 
Appendix B is a node tree diagram which illustrates four levels of that function’s 
decomposition. Material requests fall into four general categories: standard material 
request, request for material, off-line request for material, and transcripts. Each category 
entails a greater degree of manual activity. A standard material request has a transaction 
code that can be entered at the terminal and MCIAIS will generate a mailing label for 
logistics to complete he distribution process. Material in this category includes: a 


duplicate issue of job aids, course or program material, issuing course or program material 


130 


without an enrollmen:, and a duplicate issue of a completion certificate or diploma. A 
request for material is for material required to support the Marine Corps unit Training 
NCO performing MC! liaison functions. Material in this category includes: pre-addressed 
postage paid envelopes, blank DP-37s, course catalog, Marine Corps Institute Procedures 
Manuals, R-1 Cards and R-11 Cards. Activities for this type of request include filling out a 
form, packaging the material from stock maintained in the Student Services, addressing 
the package and forwarding the package to Logistics for mailing. Off-line request material 
is for an individual component of a course, program or job aid or course material for a 
foreign military officer. This requires completion of a different form, approval by 
operations officer, preparation of an address label, and delivery to Logistics for mailing. A 
transcript request must be in writing. It is delivered to the registrar for processing in 
accordance with activity SSD6.2. 

PROCESS REQUEST FOR REGISTRAR ACTION, activity number 
SSD6, models the production of transcripts and diplomas. Figure B-7, Appendix B is a 
node tree diagram which illustrates four levels of that function’s decomposition. One of 
the MISD grading program batch processes produced a diploma print file. The file is 
transferred to a disk and delivered to the Registrar. The Registrar produced the diplomas, 
duplicate diplomas and envelopes from the file by running a program on a local PC 
connected to a LaserJet printer. Transcripts must be individually researched using active 
and archived MCIAL'; student records and microfiche records. The collected data is put 


onto a form, typed en 4 computer terminal, printed and mailed. 
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Task worksheets provided to the NPS team indicated that a morning report 
ageregated the number of telephone calls processed daily, the number of examinations 
processed - successfuljy and unsuccessfully, the number of transcripts requested and 
distributed, and the number of diplomas distributed. The morning report was manually 
collated. However, that process had been terminated and no records available from which 
to extrapolate historical impact. 


c. As-Is Process Model 


The As-Is process model documents the business area analysis of the 
current system. Graphic representations helped to summarize the results. The business 
area analysis of SSD was documented with a decomposition diagram and several node tree 
diagrams. These diag.ams illustrate the functional decomposition of activities performed 
to administer studem activity records in MCIAIS. The process model is provided as 
Appendix B. 

Manual activities within a process model add definition to the business 
system architecture. The manual processes however, can lead to discontinuity in the 
information and technical architecture. A large number of manual activities prevents 
accurate measurement of throughput and associated cost. This is one reason for targeting 
their elimination during reengineering. 

C. REENGINEERING THE AS-IS PROCESS MODEL 
Reengineering approaches and methodologies were discussed in Chapter IV. This 
section addresses the business environment leading to the selection of Harrington’s 


Business Process Inn >vation (BPI)as the reengineering methodology best suited for MCI. 


Following the assessment, the BPI methodology is discussed as it applies to the current 
processes at MCI. The section concludes with a summary that leads to the development of 
the To-Be process model. 


1. Assessing the Reengineering Environment 


The information gathered during the enterprise analysis and development of the 
As-Is model was critical to understanding MCI’s business environment and the urgency 
with which reengineering may be applied. 


a. Reengineering Category 


Initially, the authors believed MCI fell into the crisis reengineering 
category. Prior to August 1996, the Commandant of the Marine Corps urged MCI to 
improve its level of customer service. Executive level interest and support were keen and 
funding was readily available. Some organizational restructuring was already underway 
and demonstrating marked improvements. In spite of the quick fixes, however, the need 
for formal reengineering of the information system still existed. 

Culturally, MCI is a traditional organizational hierarchy. As a result, MCI 
exhibited great resistance to notions of radical transformation. For example, MCI was not 
interested in suggestions of outsourcing the shipping process to a commercial package 
delivery company or moving to Internet accessible, on-line enrollment procedures for 
customers. It was evident from the first interviews that radical changes would not receive 
the support or continuity of personnel necessary to carry radical modernization to fruition. 


The incremental approach of the life-cycle reengineering category was seen as the best fit 
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based upon the expected turnover of key management personnel and procurement 
schedule of the replacement system architecture. 


b. Reengineering Ideals 


An assessment of the reengineering ideals provide perspective on MCI 
business environmeni and the degree of commitment to modernization. 

Process Orientation- MCI retains much of the outdated management 
perspective of the industrial age. It is primarily task organized in an assembly line manner. 
A major reason for this is the prevalence of combat arms personnel staffing key 
management billets. Transition to the information age 1s evident and a new information 
system a key element. Another key element is a paradigm shift from task orientation to 
process orientation and process improvement. 

Three distinctive processes are apparent at MCI. The first 1s information 
gathering and distribetion: maintaining a course catalog of over 300 items, maintaining 
the addresses and course history of over one million students, and maintaining 
examination question danks and answers for over 160 courses. The second process is 
warehousing and shipping of catalog items. The third process is course development and 
writing of text books and associated material. Many reengineering opportunities exist with 
this wide range of processes. Other initiatives, outside the scope of this project, should 
address the MCI logistics and course development processes, leaving the information 
gathering and distribution the only function available for reengineering as part of this 
project. This function is performed by the Student Services and Information Systems 


Management Divisions at MCI. 
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Ambit:on - The degree of ambition is reflected in the number of protected 
processes. It is also reflected by the amount of resistance encountered when proposing to 
reengineer a candidate process. This became obvious during the circulation of the SSD 
As-Is process model. 

Rule-breaking - The effort to reduce business rules often requires an 
understanding of existing rules in place. MCI made a genuine effort to document their 
current business rules in force. It was discovered during the process that many of the rules 
were made So that the programmer could code them. While business rules standardize 
operating procedures, complicated conditions proved difficult for Marine programmers to 
understand and implement. As a result, considerable effort was put into eliminating 
business rules attached to student enrollments. 

Creative use of information technology - Information technology (IT) 
plays a key role in BPR. MCI demonstrated considerable interest in this ideal. But due to 
limited exposure, not all personnel are aware of IT opportunities or their potential 
benefits. Additionally, the acquisition of IT resources, for the military in general, 1s often a 
lengthy process and limits the more immediate results that can be achieved. 

The delays associated with procurement of IT resources may provide the 
time for the reluctant, or undecided, stakeholders to “buy-into” the reengineering effort. 
This buy-in may facilitate the integration of all the process owners as effective participants 
in the modernization effort. In the meantime, a continuous process improvement approach 


is necessary to comp!ement the cultural environment. For these reasons, the selection of 
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Harrington’s BPI methodology was determined to be the best fit for applying business 
process reengineering techniques to MCI. 


2. Reengineering Implementation 


Harrington’s BPI methodology addresses five phases: organizing for 
improvement, understanding the process, streamlining, measurement and control, and 
continuous improvement. The authors application of these five phases discovered that 
much of the work was already performed. Further investigation found evidence that an 
external consultant had analyzed MCI and many improvements were already implemented. 

Phase I, organizing for improvement. This phase provides structure and continuity 
to a modernization effort by staffing reengineering roles. MCI had already created a 
Process Improvement Requirements (PIR) Section and formalized its importance by 
incorporating it into ‘i e organizational structure. The deputy director filled the role as 
leader. As MCI’s number two position, the deputy director is in the ideal position to 
influence reluctant sunloneee to embrace the change program, create organization vision, 
and ensure managerial and financial continuity. He briefed the Commandant, the 
Commanding General, MCCDC, and the Director, Training and Education Division to 
muster financial support for the modernization plan. A steering committee was already 
formed as the MCIAIS Redesign Team. The members included the Deputy Director, 
Executive Director, PMED chief, OSD chief, SSD chief, Logistics chief, and the 
Computer Systems Aralyst. A czar, with information systems management experience 
and previous assign ants as SSD and MISD chief, was in place. Department chief filled 


the role as process owner. An external consultant had been involved once before and the 
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addition of the NPS team provided a detached perspective as well as technological 
expertise not possessed by anyone else in the MCI. The personnel assigned to MCI were 
ready for change. 

Staffing the reengineering roles outlined above have the greatest impact on the 
success of the reengineering effort at MCI. The transient nature of a military unit makes it 
difficult to sustain long term projects. Personnel rotate through billets within a military 
organization every one to three years and not all of the personnel rotate at the same time. 
This staggered rotaticn lends stability to long term projects in a traditional, non-military 
organization by allowing personnel and policy continuity. However, the strict hierarchical 
structure of a military unit may have a destabilizing effect on long-term projects as project 
teams and objectives are influenced by the more hierarchically senior individuals. For 
example, the modernization project began in July 1995 and significant progress was made. 
In May 1997, a new deputy director was assigned and with modernization well underway, 
enthusiasm waned. The new deputy director is tasked with other time consuming duties 
and priorities that prevent him from continuing the reengineering leadership of his 
predecessor. Other reengineering roles at MCI have experienced similar dynamics. 

The reengineering czar that began the project retired in June 1997 and was 
replaced by a civilian contracted project manager. This will enhance the project’s potential 
for success because the project manager has military and database migration experience 
and is trained in both project management and reengineering techniques. The steering 


committee composition also changed as members were replaced. 
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The SSD and MISD process owner are the only roles that remained intact 
throughout the research portion of the modernization project. The addition of an Internet 
Interface process owner expected in August 1997 is viewed by the authors as a plus for 
the potential success of the modernization as the replacement has a masters degree in 
Information Technology Management and is already familiar with the MCI modernization 
project. 

MCI organizational structure is also unduly influenced more by the government 
worker placement policy and practice than by sound reengineering principles. In June 
1996, the PIR Section was formed with two civilian employees. Their former MCI 
positions were eliminated as a result of downsizing. These employees were transferred to 
MCI’s operations department and chartered to “improve the MCI process.” Steeped in 
TQL tradition, the “process improvement team” had no concept of process modeling, 
work flow analysis, or other techniques necessary to conduct reengineering. 

With the exception of the project manager, the process improvement team and 
other members filling reengineering roles, have no formal reengineering technique training. 
To ensure project success at MCI emphasis must be placed on filling all of the billets on 
the reengineering tean: with competent and motivated personnel. 

Phase I], understanding the process. This phase focuses on data collection and 
modeling. The process owners had a thorough understanding of what their processes did 
and what they wanted their processes to do. The objective of the NPS team was to 
document this awareness. Much of the data collection had already been accomplished, 


customer interviews, task breakdown worksheets, flow charts, mission statements and 
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models, by the previous consultant. The authors believe that most of the models were not 
presented to MCI in an expected form, to their understanding and without tools for 
continued maintenance. 

Phase II], streamlining. This phase concentrates on the reengineering effort. 
Process elimination traditionally accounts for a significant contribution to reengineering 
benefits. When applying the reengineering principles and analyzing the As-Is process 
model looking to eliminate non-value-added processes, it was discovered that due to the 
sequential nature of SSD tasks, many of the non-value-added tasks had already been 
removed. For example, reporting the number of DP-37s, phone calls, or transcript 
requests processed on a morning report. No one used this information and it was manually 
intensive to collate. 

Most processes had already been simplified. For example, the enrollment 
procedures for Marines through the unit diary, and pre-packaging a new DP-37 with 
course material for faser distribution have reduced customer response time. Additionally, 
SSD functions are sequential because subsequent tasks depend upon completion of the 
previous ones. Figure 24 illustrates this sequence. As and example, SSD enrolls students 
in courses; tests their comprehension by issuing and grading examinations; stores student 
course history; and issues transcripts. Transcripts cannot be issued without course history 
and exams cannot be graded without enrollment. 

The remaining reengineering effort had to focus on automating manual tasks and 
methods to capture data only one time. The most dramatic impact on this effort will be 


made by implementing the network accessible relational database technology, MCIAIS-II. 
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Figure 24. SSD Sequential Process Flow. 


The response time of user interaction will be reduced by eliminating multiple entry 
requirements. Graphical user interface (GUI) will be updated and more responsive to user 
requirements. The database itself will be more flexible - easier to modify and adjust with 
the more frequent changes commonly encountered in today’s business environment. A 
relational database prevides facilitates flexible query and customized report generating 
capability. 

One method to take advantage of a new relational database is redistribution of 
selected batch processes. Batch processing is currently used at MCI to update MCIAIS 
with transactions from the grading program, unit diary transactions downloaded from 
MCTEFES, and input through daily transactions. Other batch processes generate transaction 
files for yet other batch process to execute: the grading program creates a diploma print 


file, a completion cert:ficate file and an error listing file; enrollments and standard material 
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requests Create a mailing label file; another program creates a motivation card file. Finally, 
there are batch processes used to produce the output of transaction files: printing mailing 
labels for material dissibution, printing UARs in the monthly cycles, copying the diploma 
file to disk for the registrar to print. These type of transactions are necessary because of 
the different paper stock the output requires: mailing labels on a standard 3 % inch by 1 % 
inch self-adhesive label, motivation cards and completion certificates are on preprinted 
stock, diplomas require laser quality print on heavy gauge stock. 

Running the grading program “on demand,” would allow SSD greater control of 
their own schedule and possible facilitate faster processing of examinations, diplomas, and 
error listing. “On demand” processing could prove very productive for the UAR 
processing. Over 1500 UARs are generated in the monthly close out cycle. Responses to 
the UAR are received over a short period of time and not much time is available to 
process all responses prior to the next cycle. The distribution and response load could be 
distributed more every over the month. The SSD clerk would have more time for 
processing before the ext cycle. 

Private sector businesses rely heavily on its efficient processing of customer input. 
That 1s how orders are received, goods are sold and income is generated. Not only are 
requests for enrollment processed through A single point of entry, but also grading 
examinations, requests for materials or information, and processing of unit reconciliation 
reports. If MCI charged customers for their products and depended on the processed 


payments, using current procedures, they would go broke. 
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Modern technology has enabled businesses to cut costs by moving to a paper-less 
work environment. MCI should take advantage of IT to follow suit. A concentrated effort 
should be directed at utilizing current IT solutions to replace the manual tasks involved 
with obtaining customer input by concentrating of the process principle of “capture 
information once, at the source.” Alternate modes of enrollment should be utilized. 
Student services realized a significant improvement by enrolling Marines through the unit 
diary. The burden of data entry was shifted from student services clerk to the unit diary 
clerk and MISD batch processing. Similar improvement can be achieved by utilizing the 
Internet for enrollmen:, status query, material requests, examinations, and changes to 
student information. Many of the same processes can be achieved interactive voice 
response systems (IVRS). (Curnd, 1994) 

More efficient processing of electronic mail can be realized by combining a filtering 
agent and establishing standards for electronic mail sent to the MCI OMB. Most fultering 
agents allow the user to specify specific words that appear in the “From” or “Subject” 
fields of the e-mail. On that precept, rules can be designed to sort incoming e-mail’s 
subject line and dist: ‘dute to the appropriate section’s OMB for processing. Subject line 
standards should be published in the next revision of the Marine Corps Institute 
Procedures Manual can MCI Internet Web Page. The Web Page can even pre-format the 
message for the customer. Filtering agent technology is rapidly advancing, such that 
enrollments or queries could be done by e-mail and a response generated by the computer 


without human intervention. (Currid, 1994) 
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An Internet based web page can used to publish the course, the Marine Corps 
Institute Procedures Manual, telephone contact directory, as well as a Frequently Asked 
Question (FAQ) library. Customer access to this information could reduce the number of 
telephone calls entertained by the immediate assist clerks. 

Digitized course materials and electronic distribution upon accepted enrollment 
could reduce the production, warehouse and inventory overhead. This requires further 
analysis of the available and required bandwidth, as well as customer access. A deployed 
Marine, soldier, sailur or airman may have limited or no access to the Internet or a PC to 
complete a course in digitized form. 

Development of a Unit MCI module that automated the manual task of local 
record keeping would earn praise from training NCO around the Marine Corps. Presently, 
the training NCO manually prepares a R-5 card when a Marine wants to enroll in a course 
or program. The form is forwarded to the unit diary clerk for data entry into MCTFS. 
Automating the form such that it populated the unit MCI database and generated either a 
standard electronic mail or batched and transmitted to MCI could bypass using MCTFS 
and the unit diary for enrollment. Include a reconciliation application in the module and 
UAR could be done with minimal human intervention and improved efficiency. 

For those activities that must use paper, apply the process principle: “Perform 
work where it makes the moSt sense” suggesting, mail sorting and segregation could be left 
to the postal service prior to distribution within MCI. Utilizing the last four digits of the 
nine digit zip code could contribute to faster distribution of incoming mail. Faster 


distribution of customer input translates to more parallel processing. Automated mail 


143 


handling equipment is another solution that could accelerate distribution of incoming mail, 
as well as capture and measure the throughput. 

Integrating the Logistics Department’s inventory and automating additional 
logistics functions into MCIAIS would improve material distribution and improve SSD’s 
visibility of student material. The use of bar-coding can monitor the progress of material 
through the packaging and distribution cycle. Shipping status would become available to 
the SSD clerk when responding to student inquiries. Monitoring the distribution cycle can 
also identify other candidates activities for improvement. 

Phase IV, measurement and control. This phase implements a system to control 
the process for continued improvements (Harrington, 1991). This builds on the process 
model by adding performance measures for the reengineered processes. Ideally, the 
process modeling technique and CASE tool selected support reporting the performance 
criteria. DoD and the FPI methodology emphasize using activity based costing as one 
measurement method. Additionally, responsibility for model maintenance should be 
established for continuity. 

The PIR Section is ideally suited for the responsibility of model maintenance. It is 
staffed by civilian personnel which is an uncommon advantage for a military activity. Such 
staffing can provide necessary continuity to monitor performance. The personnel are well 
trained in Total Quality fundamentals. They need additional experience with process 
modeling, process improvement methodology, activity based costing, and information 
technology opportunities. Their lack of experience in these areas detract credibility from 


their assignment in the PIR Section. 


The IDEFO modeling technique for process modeling allows for representation of 
mechanisms, personnel, equipment, etc. in each process. Process modeling can represent 
performance measures. Performance measures describe the work done and the results of 
that activity (Turney, 1991). Modeling can eliminate the seemingly wasted effort in manual 
efforts. In addition tec IDEFO modeling, BPWin® can integrate activity based costing 
categories and represent totals within the model. Activity based costing provides two 
dimensions to use in process reengineering: cost assignment view and process view. 
Together they can direct MCI toward a more efficient product and service strategy. 
Incorporating activity based costing will help MCI realize additional benefits in process 
measurement for continuous improvement in their modernization effort. 

Phase V, continuous improvement. This phase emphasizes continuous monitoring 
of improved processes for continued excellence. This depends on maintenance of the 
process models by monitoring the reengineered processes and periodically evaluating 
performance measures. MCI must develop a data and process model, maintain it, and use 
it for the benefits the models provide. Part of the justification for migrating from the 
legacy system was based on the lack of code documentation. A new system can Be enence 
the same fate if not p:uperly maintained. Additionally, the models enable prototyping 
which can reduce anx:ety of implementing changes without adequate testing. 


3. Reengineering Summary 


Despite the numerous opportunities identified in the previous section, 
reengineering the As-Is model focused on migrating the current functionality to MCIAIS- 


IJ. The lengthy acquisition process and costs associated with many of the IT solutions 
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would not be achievable prior to the expected delivery of the new computer. The objective 
shifted to producing a process model that reflected the information system it would 
immediately represent and an information system model the designers could use to 
program. 

The To-Be process model did not include activity based costing (ABC) because 
there was insufficient data made available with which to model. The author’s felt that 
ABC would further complicate a process model, a concept not easily appreciated outside 
of MISD. There was already enough new knowledge required and a new costing paradigm 
might put the models on a shelf never to be found. 

With the majority of processes already streamlined and non-value-added processes 
dependent on automated equipment not available, reengineering efforts turned to 
minimizing redundant data entry, integrating similar processes and data sharing. These 
three problem areas are well suited for information technology solutions. Specifically, 
these three areas can all be improved with implementation of a relational database 
application. In effect automating tasks by eliminating the need to re-key a customer’s data 
when fulfilling multiple requests or bouncing between screens. Other reengineering 
benefits can be reaped by redistributing and eliminating some of the batch processes 
performed by MIS. Moving the functions of grading, UAR file generation, and diploma 
printing to SSD workstations allow the user to execute the programs “on demand.” 


D. TO-BE PROCESS MODEL FOR SSD 


The To-Be process model represents the redesigned business activity of the 


student service support business area. It resulted from reengineering selected processes of 
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the As-Is process monel. The implementation of an automated information system based 
on relational database technology, a dramatic reduction in the number of primitive level 
processes was realized. Despite the reduced number of processes, SSD customer service 
response time will decrease because of the data sharing capability. SSD can be further 
improved by incorporating a portion of the MISD As-Is processes into the SSD To-Be 
model. As-Is MISD functions that could be run from SSD workstations “‘on demand”’ 
include: the grading application, UAR file generation, and diploma printing. 

1. To-Be Model Details 

All of the activities depicted in the SSD process model are prefixed with “T.” The 
entire node tree diagram is too large to print as one document so it was divided into 
several diagrams representing various levels. The remaining model details must be gleaned 
from careful study of the model components included as Appendix C. 


a. Business Area Decomposition 


Functional decomposition of the To-Be model started at the business area 
level from the enterprise analysis. It reconstructed the decomposition of the As-Is model 
using the reengineered processes. A total of 114 activities and 120 arrows were identified 
and defined. The business area Student Service Support was decomposed six levels down 
to primitive processes. The first level identified four functions: CUSTOMER 
SERVICING, STULENT ACTIVITY SERVICING, GRADING, and REGISTRAR 
SERVICING. Figure <°-1, Appendix C is a node tree diagram of all the activities of 


Student Service Support. 
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The CUSTOMER SERVICING - T1 function was decomposed into two 
processes: OBTAIN CUSTOMER INPUT and PROVIDE UNIT ACTIVITY. A significant 
number of processes were reduced by taking advantage of the capabilities of the relational 
database. Instead of representing each different type of processing for changing or 
servicing a Student’s record, a CALL arrow was used to one of the processes represented 
under activity T2. The As-Is activity representing the Conversant AVRS was removed 
from SSD processes and moved to MISD. Maintaining AVRS is strictly a database 
administration process. Servicing a Marine Corps unit reconciliation processes were 
reduced with the CA’_L procedure mentioned above and a process to represent the ability 
to request UAR “on demand” was added. 

The STUDENT ACTIVITY SERVICING -T2 function was decomposed 
into five processes: PROCESS ENROLLMENT, PROCESS STATUS REQUEST, 
CHANGE STUDENT INFORMATION, PROCESS ADMINISTRATIVE ACTION and 
PROCESS REQUEST FOR MATERIAL. All processes representing a change input to 
change a student’s record is represented in this function. The graphical user interface 
should lead the user to the desired action much quicker than possible in the As-Is model. 
Transaction codes are no longer required as most relational database have an inherent 
transaction code log. An measurement feature can be incorporated to indicate the 
student’s mode of requesting the change (i.e., telephone, e-mail, walk-in, UAR, etc.). 
Material request processing was automated by eliminating the use of manual forms for 
‘Request for Material” and “Off-line Material” requests. Routing for approval can be 


accomplished by the DBMS application if still required. 
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The GRADING -T3 function was decomposed into four functions: 
PROCESS DP-37'S, PROCESS HAND GRADED EXAMS, RUN GRADING 
PROGRAMS and PROCESS OPSCAN ERRORS. This process still has a lot of manual 
processes represented. The OCR readable exams issued and the two different sized forms 
was a limiting factor. An “on demand”’ process was added to facilitate running the 
program to grade exams data collected from the scanned DP-37s. The “on demand” 
facility provides an added feature to work the OPSCAN error listing “on demand” as well. 

The REGISTRAR SERVICING - T4 function was decomposed into two 
functions: [SSUE DIPLOMA and ISSUE TRANSCRIPT. An “on demand” feature was 
added to allow the user to print diplomas at any time following the execution of the 
grading program. The transcript production reflects automated transcript generation based 
on user provided information for the transcripts requested by former students whose data 
has been archived on microfiche. The transcript application would be programmed to draw 
all student informaticn from MCIAIS to complete a transcript from an internal template. 

b. To-Be Process Model 

The To-Be process model documents the business system model for the 
new information system of MCI. Graphic representations helped to summarize the result. 
The To-Be process model consists of a functional decomposition diagram (Table C-2, 
Appendix C), an activity dictionary (Table C-3, Appendix C), an arrow dictionary (Table 
C-4, Appendix C), the node tree diagram (Figure C-1, Appendix C), the context diagram 
(Figure C-2, Appendix C) and an IDEFO kit (Figures C-3 - C-37, Appendix C) presenting 


the process decomposition down to the primitive levels. 
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Not all of the manual activities could be eliminated. They remain in the 
process model to provide complete definition to the business system architecture. Future 
continuous improvement efforts should focus on reengineering principles to further reduce 
their persistence and increase process efficiency. Additionally, shifting to a process 
improvement oriented accounting approach, such as activity based costing, would help 
realize the true cost of delaying further process improvements. 


2. Information System Model 


The SSD information system model represents what data the system manipulates, 
captures, and stores in the MCI To-Be process model. While this thesis focuses on the 
first two stages of the information engineering methodology, a proof-of-concept prototype 
is an objective of the MCI modernization project. Design and construction of the 
information model is beyond the scope of this thesis, however, information system 
prototype development requires a different view of the data and process models. Asa 
result, an information model was developed to facilitate prototype development. As noted 
in Chapter V, there a-e three parts to the model: (1) DFDs depicting information system 
process decomposition, (2) definitions of all of the symbols on each of the diagrams, and 
(3) process specifications at the primitive process level. The information system model 
serves as a bridge between the data and process modelers and the prototype developer. 


a. DFDs 


As noted in Chapter V, the first step in developing an information model is 


to remove the manual processes from the To-Be model. The SSD system context diagram, 
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shown in Figure 25, shows the SSD System and the outside entities. A context diagram is 


the highest level of the DFD. 


MCCTA 










UD Output 








MCTFS Marine 


information aca ~ 


Course, Program & SSD SYSTEM 


Logistics Information Material, Course/Program Status 













MC} 


Departments MC! Customer 






Invoice Data Customer Information + 
Customer Request 


Figure 25. SSD System DFD: Context Diagram. 


Functional decomposition techniques, described in Chapter V, are applied 
to the context diagram to create the next level of the DFD, diagram 0. Figure 26 shows 
the five major automated processes of the SSD information system model: (P-1P) Display 
Catalog, (P-2P) Update Marine Information, (P-3P) Interface with Unit Diary, (P-4) 
Order Material, and (P-5) Service Student. Each of these processes is further decomposed 
to the primitive level. The prototype developer uses these diagram in conjunction with the 
symbol dictionary and process specifications to code the prototype. 

All of the processes hierarchy numbers depicted in the SSD information 
system model are pre71xed with “P” for process. All of the data store hierarchy numbers 
depicted in the SSD information system model are prefixed with ““D” for data store. The 
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Figure 26. SSD System DFD: Diagram 0. 


suffix “P” indicates primitive level processes. Figures 27 and 28 illustrate two of the 
primitive level DFD diagrams for the SSD processes illustrating DFD techniques. The 
remaining decomposition diagrams are too large for inclusion in this thesis but may be 
viewed in NPS-SM-97-006: Analysis, Design, and Prototype Implementation of a 
Contemporary Inforrration System for the Marine Corps Institute, Final Report (Kamel 
et al., 1997). 

Data stores are also decomposed in a way similar to processes. The 
technique was devised to aid developers and analysts working with large numbers of 
database tables. The same parent/child relationships that apply to processes also apply to 
data stores and its use prevents cluttered and confusing diagrams. Figure 29 shows how 
the SSD database, MCIAIS-2, is decomposed into subordinate data stores. This first 


subordinate decomposition diagram is a logical grouping of data entities. Decomposition 
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Figure 27. SSD System DFD: (P-1P) Display Catalog. 
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Figure 28. SSD System DFD: (P-5.9.3P) Determine Pass/Fail. 
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Figure 29. MCIAIS-2 Data Store Decomposition. 





continues until actual data model table names are identified and assigned a hierarchy 
number. Figure 30 iljustrates how the logical data store (D-1.4) Logical Student History is 
decomposed further into five actual database tables: (D-1.4.1) STUD_CRS_EXAM_xX, 
(D-1.4.2) STUD_CRS_X,: (D-1.4.3) STUD_PRG_X,: (D-1.4.4), 


STUD_CRS_TRAN_X (D-1.4.5) STUD_PRG_TRAN_X. 
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Figure 30. SSD System DFD: (D-1.4) Logical Student History Data Store 
Decomposition. 





b. DFD Symbol Dictionary 


The DFD decomposition diagrams are accompanied by the DFD symbol 


dictionary. Without the dictionary, it is difficult for a prototype developer to distinguish 
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data table names witi the precision necessary to code the prototype. For example, two 
data table names in the data model are ERR_CODES and ERR_LIST Although the be 
names may be distinctive to the data modeler, implementation coding and debugging may 
frustrating to the programmer because a data element may be coded to read from the 
incorrect data table. 

The DFD symbol dictionary 1s arranged alphabetically and contains an 
entry for each of the 214 symbols that appear in the diagrams. Each page of the dictionary 
contains columnar headings for symbol name and hierarchical number (data flows are not 
assigned a number), type of symbol, description, and the DFD diagram number where 
the symbol appears. !r addition to alphabetical appearance, font type and size is used as to 
further aid dictionary use. Processes are listed in all capital letters, and data flow are listed 
in ten pitch title case. Figure 31 is an excerpt from the dictionary. The entire dictionary 
may be viewed in NPS-SM-97-006: Analysis, Design, and Prototype Implementation of 
a Contemporary Information System for the Marine Corps Institute, Final Report (Kamel 
Cledlealeeoe 


c. Process Specifications 


Process specifications summarize the data input, output, and logic of each 
of the primitive processes. Only primitive level processes are included as parent processes 
are an aggregated collection of the children's inputs, outputs, and logic. A typical process 
specification for a primitive level process 1s shown in Figure 32. Process specifications for 


entire model may be viewed in NPS-SM-97-006: Analysis, Design, and Prototype 
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DED Symbol Dictionary 


Name Symbol Type Definition DED 
CrsOnHandQty Data Flow Data element definitions can be found in the P-4 4P 
Attribute Definitions Report (Exhibit 5, Appendix A) 
Current Course Request Data Flow Course requested: that is current version P-5 10.1P 
P-502e 





- 





SUS7T (D-1.5.1) Data Store CustSSn_ID + State + CustLastName + D 
CustFirstName + CustMidinit + CustDSN + 
CustCommNo + CustAddr1 + CustAddr2 + CustCity | . 
+ CustZip 


Data Flow Customer Instance 







5 
> 
Current Program Request |Data Flow Program requested: that is current version P-5.10.1P 
P=o. 90.2) 
1 
P 
P-4 


i 
2 
1 
e 





Customer Identity 










Data Flow Name, rank, SSN, grade, service component, lcontext 
address, and telephone number. P-0 


Customer Information 


Data Flow CustSSn_ID + State + CustLastName + 
CustFirstName + CustMidint + CustOSN + 
CustCommNo + CustAddri + CustAddr2 + CustCity 
+ CustZip 


Customer Instance 





a customer: status, information, transcript request, 
request for material, etc. 












DETERMINE IF STUDENT |Process Compares the requested course or program P-5.10 
MEETS PREREQUISITES prerequistes to the student's course history. 
(P-5.10.3P) 

DETERMINE OF Process Checks for SSN match to a student SSN in the MCI |P-5 


STUDENT IS IN DATA student data base. 
BASE (P-5.1P} | 


DETERMINE PASS/FAIL {Process 
(P-5.9.3P) 


iDiploma =< Pe Flow 











Comipares number student's exam correct answers 
to the minimum passing score for that exam. 


The certificate issued to the student for passing all |P-59 

lof the course exams that make up aprogram. The |P-5.9.6P 
diploma is accompanied by a letter indicating 
transript information for the program and summary 
of the included courses. 


DISENRQLL STUDENT Process Disenrolls a student from a course he/she is enrolled} P-5 

(P-5.6F) in 

Disenrolled Data Flow Data element definitions can be found in the 
Attribute Definitions Report (Exhibit 5. Appendix A) 

Data element definitions can be found in 


the Attribute Definitions Report SSD Process Model 
(Exhibit 5, Appendix A) Exhibit 28, Appendix B 
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Figure 31. Excerpt From DFD Symbol Dictionary. 
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Process Specification Form 
Process Number: P-5.9.6P 
Process Name: PRINT DIPLOMA 
Input Data Flow: 
Program Completion Information 
Student Identity 
AD Marine Student Address 
Marine Reservist Address 
NonMarine student Address 
Output Data Flow: 
Diploma 
Invoice Instance 
PrgDiplssueDate 
Tran_ID + SP_TransDate_ID 
Module Logic: 
For each program completion 
GET Student Identity 
appropriate address 
UPDATE Student Program History 
CREATE Invoice Instance 
FORMAT & PRINT Diploma 


Figure 32. Process Specification Form for (P-5.9.6P) Print Diploma. 





















Implementation of a Contemporary Information System for the Marine Corps Institute, 
Final Report (Kamel et al., 1997). 


3. Application Mapping 


A Process versus Data Entity (CRUD) Matrix was developed from the To-Be 
process model. The CRUD Matrix maps the process activities to the data base tables and 
is included as Figure C-38 of Appendix C. The CRUD Matrix validates: 1) that all of the 
data model entities have a purpose in the process model, and 2) that the data model 
contains only the entities required by the process model. 

Clustering the CRUD Matrix results in the Clustered CR Matrix. Every “C’, “U”, 
and “D” was replaced with a “C”’ as described in Chapter IU. BPWin® did not perform an 


automated clustering. A manual procedure was necessary. All of the BPWin entities 
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representing transient data created in the process model were removed from the CRUD 
Matrix. All of the manual processes were also removed as well since there was not a data 
entity with which to associate. The remaining relationships were arranged to form groups. 
Analysis of the groupings that result from the Clustered CR Matrix reveal four 
SSD applications: Student Servicing, Unit Servicing, Grading, and Registrar. A fifth 
application, Executive Summary Information, was identified to provide management with 
the adhoc query capability achievable with a relational database. The logical and physical 
distribution of the five applications throughout SSD 1s described in another team members 
thesis (Evers, Jr., 1997). The CR Matrix is included as Figure C-39, Appendix C. Table 5, 


details the capability of each of the applications. 


Application Capability 


On-line Course Catalog Access, Enrollment, Disenrollment, 
Course History Access, Order Materials 


Student Servicing 


On-line Course Catalog Access, Enrollment, Disenrollment, 
Course History Access, Order Materials , VAR Generation 


Unit Servicing 


Grading Grading, Course History, Student History 

Registrar On-line Course Catalog Access, Course History, Transcript 
Generation 

Executive Summary On-line Course Catalog Access, Predefined SQL Query 

Information Capability 


Table 5. Recommended Application Capability. 
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VII. SUMMARY, RECOMMENDATIONS, AND CONCLUSIONS 


This chapter provides a summary of the thesis as well as recommendations and 
conclusions. First it addresses the research questions and objectives presented in Chapter 
]. Next it summarizes the enterprise analysis methodology, process modeling, and a 
recommended reengineering plan for the Student Services Department at MCI. 
Additionally, it includes implementation recommendations and some anticipated obstacles. 
The chapter concludes with suggested topics for future study and conclusions. 


A. ACHIEVEMENT OF RESEARCH OBJECTIVES AND QUESTIONS 


This research is the result of a year long project commissioned by MCI to develop 
the architecture and supporting migration plan to transition from a closed, non-relational 
system to an open, client/server based relational database management system (DBMS). 
The research and development was conducted by a six member team at the Naval 
Postgraduate School. The objectives of this research project were achieved: enterprise 
analysis was conducted, business area analysis of the SSD was conducted, data and 
process models were developed, the process model was reengineered, an information 
system was designed and, a proof of concept prototype was produced. If implemented, the 
modernization plan w:ll make the SSD more efficient and effective at providing service to 
their customers. 

In the course of this project, the research questions posed in Chapter I were 
answered. These questions and their answers are outlined below. 


e Can a process model be developed to reflect the current business process of 
the Student Services Department of the Marine Corps Institute (MCI)? 
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A detailed As-Is process model was created using IDEFO modeling techniques for 
the Student Services Department of MCI. The model diagrams and the data dictionary are 
included in NPS Technical Report NPS-SM-97-006: Analysis, Design, and Prototype 
Implementation of a Contemporary Information System for the Marine Corps Institute, 
Final Report (Kamel et al., 1997). The model conforms to the DoD standard for process 
modeling and can serve as a baseline process model for future reengineering efforts. 


e Can the business process of the Student Services Department of MCI be 
reengineered? 


The SSD business process can only be reengineered to a limited extent due to the 
nature of MCI work flow as well as budgetary constraints. There are no tasks 1n the SSD 
process that can be eliminated because of the sequential nature of the SSD work flow. 
However, reengineering benefits can be gained from implementation of a shared relational 
database that eliminates redundant data entry, publication of the course catalog on the 
Internet, and develop-nent of on-line enrollment forms to further increase the efficiency 
and effectiveness of tie Student Services Department. 


e Cana prcc2ss model be developed to reflect the reengineered business process 
of the Student Services Department of MCI? 


A To-Be process model was created using IDEFO modeling techniques for the 
Student Services Department of MCI. The model diagrams and the data dictionary are 
included in NPS Technical Report NPS-SM-97-006: Analysis, Design, and Prototype 
Implementation of a Contemporary Information System for the Marine Corps Institute, 


Final Report (Kamel et al., 1997). The model conforms to the DoD standard for process 
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modeling and can serve MCI as an example and first iteration of an ongoing reengineering 
effort. 


e What BPP. methodology is most suitable for reengineering the Student 
Services Department of MCT? 


Of the four BPR methodologies surveyed, Hammer and Champy’s Business 
Process Reengineering, Thomas Davenport’s Process Innovation, H. James Harrington’s 
Business Process Improvement, and DoD’s Functional Process Improvement (FPI), no 
one methodology was identified as a perfect fit for reengineering the SSD. Each 
methodology has strengths and weaknesses that effect its use in the MCI business 
environment. Elements of all four methodologies were applied with particular emphasis on 
the business process improvement methodology of H. J. Harrington. 


e What CANE tool is most suitable for reengineering the Student Services 
Department of MCI? 


Although BPwin® was the CASE tool selected and used for process modeling, 
System Architect/BPK Professional would have been a better choice because it offered 
one central repository for both data and process model metadata and a more versatile 
DFD graphics capability. Despite the advertised compatibility of BPwin® with its sibling 
data modeling tool ERwin®, initial metadata transfer between the two tools was less than 
perfect. During the course of the project, it was necessary to request a software patch 
from the vendor so that data model definitions could be imported into BPwin®. 


e Cana CRUD diagram be developed to support the BPR of the Student 
Services Department of MCI? 


A CRUD matrix for the SSD was generated and clustered. The CRUD matrix, 


containing 44 data ennties and 113 functional activities was clustered manually because 
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none of the reviewed CASE tools had that capability. BPwin® did have a CRUD matrix 
module that generated the CRUD matrix on a Microsoft Excel spreadsheet but needed to 
be refined and adjusted manually because of the model’s large size. 
B. SUMMARY OF PROCESS MODEL DEVELOPMENT 

Process model development was conducted according to the first two stages of 
James Martin’s information engineering methodology: enterprise level analysis and 
business area analysis. Within these two stages, information about the organization is 
gathered and analyzed with matrices and diagrams to produce an As-Is model. The As-Is 
model is then reengineered to produce the To-Be model. The DoD standard IDEFO 
modeling technique is used for both process models. This process takes some time to 
complete but ensures sufficient detail for sound analysis. 
C. IMPLEMENTATION RECOMMENDATIONS 

The following recommendations are suggested for reengineering implementation at 
MCI. 

e Examine the set of high level matrices developed in this study that show the 
relationship between entities. functions, organization units and locations. Use 
the inforn.ation obtained from the matrices to review the mission, functions, 
goals, organization Structure, and the information needed to run MCI business. 


e View reengineering at MCI as an ongoing effort and supported by the 
information systems architectures, methodologies and tools. 


e Establish a priority and schedule for developing, refining, and reengineering the 
business area process, beyond the student services functions, according to the 
business areas identified in this study. 


e Utilize a single database to facilitate data sharing among MCI departments, 
streamline processes, facilitate automation, eliminate data redundancy, and 
improve customer service. 
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e Utilize Activity Based Costing (ABC) methodology to identify cost drivers in 
SSD. Like most DoD activities, capturing and distributing cost data is not a 
common practice. 

e Facuitate further SSD reengineering with the development and collection of 
measures of effectiveness (MOE) and measures of performance (MOP). 
Properly cnosen MOPs and MOEs are critical to the evaluation of process 
improvements and wul help identify other candidate processes for 
improvement. 

e Consider the development of a Training NCO Interface Application. This 
application would essentially manage the Training NCO’s R-5 file on a local 
database and would reduce manual data input for the new system. 

D. ANTICIPATED OBSTACLES 

Organizational issues such as fiscal limitations, politics, cultural bias, and top-level 
leadership support must be considered. IS managers must be able to face these challenges 
effectively, or the technical issues discussed in this work will have little impact on the 
success of future system deployment. These issues are beyond the scope of this thesis. 
E. FUTURE RESEARCH REQUIREMENTS 

Many inforni:.ion technology solutions have reengineering applicability to the 
business areas at MC]. However, before they are blindly applied, a thorough business area 
analysis, similar to the one conducted in this thesis on the Student Services Department, 
must be conducted on each of the remaining business areas. The two business areas with 
the most interaction with SSD are the logistics and the program and course development 
departments. 
F. CONCLUSIONS 


To deploy and operate effectively and efficiently in the information age, DoD 


organizations must ta’e a serious look at the way they conduct business and implement 
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their processes. A detusiled process analysis of a business area provides an opportunity for 
redesigning/reengineering to reduce costs, improve efficiency, and better meet the needs 
of customers. The de ,elopment of an enterprise wide model and detailed data and process 
business area models are the necessary building blocks for developing and deploying 
information systems that support the mission and objectives of the organization. 
Adopting a methodology based on the development of the three models 
(business/process, data and technology) is extremely important for successful redesign at 
both enterprise and business application area levels. The development of a detailed As-Is 
business process model is necessary to thoroughly understand the processes of the 
different departments of MCI and for successful reengineering. There are a variety of 
modeling techniques available, as well as numerous CASE tools which support these 
models. Managers fic2 the dilemma of which tools and strategies to select when dealing 
with the migration fron legacy systems to open, relational information systems. This 
research supports the use of an information engineering methodology coupled with IDEF 
modeling techniques and a suitable CASE tool which supports synchronization of process 
and data models. This approach will allow for successful migration to open, client/server 


information systems. 
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APPENDIX A. BPR METHODOLOGIES 


This appendix contains details of the business process reengineering methodologies discussed in 
Chapter III. 


a. Hammer , Champy, and Stanton 
For more information consult the following books: 


Michael Hammer, James Champy, Reengineering the Corporation : A Manifesto for Business Revolution, 
HarperBusiness, New York: 1994. 


Michael Hammer, Steven A. Stanton, The Reengineering Revolution : A Handbook, HarperBusiness, New 
York: 1995. 


b. Thomas Davenport 
From Thomas H. Davenport, Process Innovation: Reengineering Work through Information 
Technology, Harvard Business School Press, Boston: 1993. 


Davenport’s Five Phases of Process Innovation 
PHASE J: IDENTIFY PROCESSES FOR INNOVATION 


Key activities: -Enumerate major processes 
-Determine process boundaries 
-Assess strategic relevance of each process 
-Rends- high-level judgements of the “health” of each process 
-Qualii. the culture and politics of each process 


PHASE II: IDENTIFY CHANGE LEVERS 

Key activities: -Identify potential technological and human opportunities for process change 
-Identify potentially constraining technological and human factors 
-Research opportunities in terms of application to specific processes 
-Determine which constraints will be accepted 


PHASE III: DEVELOP PROCESS VISION 
Key activities: -Assess existing business strategy for process directions 
-Consult with process customers for performance objectives 
-Benchmark for process performance targets and examples of innovation 
-Formulate process performance objectives 
-Develop specific process attributes 


PHASE IV: UNDERSTAND EXISTING PROCESSES 

Key activities: | -Describe the current process flow 
-Measure the process in terms of the new process objectives 
-Assess the process in terms of the new process attributes 
-[dentty problems with or shortcomings of the process 
-Identifv short-term improvements in the process 
-Asse::s current information technology and organization 


Jey 


PHASE V: DESIGN AND PROTOTYPE THE NEW PROCESS 


Key activities: -Brainstorm design alternatives 
-Assess feasibility, risk, and benefit of design alternatives and select the preferred 


process design 


-Prototype the new process design 
-Develop a migration strategy 
-Implement new organizational structures and systems 


c. H. James Harrington 
From H. James Harrington, Business Process Improvement: The Breakthrough Strategy for 
Total Quality, Productivity, and Competitiveness, McGraw-Hill, Inc.: New York, 1991. 


Harrington’s Five Phases of Business Process Improvement (BPI) 


PHASE I: ORGANIZING FOR IMPROVEMENT 
Objective: To ensure success by building leadership, understanding, and commitment 


Activities: 


1. Establish Executive Improvement Team (EIT) 

2. Appcint a business process improvement (BPI) champion 
3. Provide executive training 

4. Deveiop an mmprovement model 

5: 
6 
7 
8 
9 


Communicate goals to employees 


. Review business strategy and customer requirements 
. Select the critical process 

. Appoint process owners 

. select the process improvement team (PIT) 


PHASE II: UNDERSTANDING THE PROCESS 


Objective: To understand all the dimensions of the current business process 


Activities: 


ay 


CONVO WNNANPWHY 


. Define the process scope and mission 

. Define process boundaries 

. Provide team training 

. Develop a process overview 

. Define customer and business measurements and expectations for the process 


Flow diagram the process 


. Collect cost, time, and value data 
. Perform process walk-throughs 

. Resulve differences 

. Update process documentation 


PHASE II: STREAM)LINING 


Objective: To improve te efficiency, effectiveness, and adaptability of the business process 


Activities: i 
| oe 


COOn NA HR W 


Prov.de team training 
Idencfy improvement opportunities: 


Errors and rework High cost 
Poor quality Long time delays 
Backlog 


. Eliminate bureaucracy 

. Eliminate no-value-added activities 
. Simplify the process 

. Reduce process time 

. Error-proof the process 

. Upgrade equipment 
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9. Standardize 

10. Automate 

11. Document the process 
12. Select the employees 
13. Train the employees 


PHASE IV: MEASUREMENT AND CONTROL 
Objective: To implement a system to control the process for ongoing improvement 
Activities: 1. Develop in-process measurements and targets 

2. Establish a feedback system 

3. Audit the process periodically 

4. Establish a poor-quality cost system 


PHASE V: CONTINUOUS IMPROVEMENT 

Objective: implement a continuous improvement process 

Activities: . Qualify the process 

. Perform periodic qualification reviews 

. Define and eliminate process problems 

. Evasuate the change impact on the business and on customers 
. Benchmark the process 

. Prov:de advanced team training 
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d. DoD Functional Process Improvement (FPI) 
From DoDInst 8020.1M 


A 25-step methodology has been developed that will take an FPI project team from developing a strategic 
plan to the development of a final functional economic analysis (FEA) or business case. It is important to 
note that an organization may have already completed some of the steps of the methodology through other 
means such as Total Quality Management (TQM) initiatives or an Information Systems Planning (ISP) 
effort. The information generated as a result of these efforts will greatly reduce the amount of time 
necessary to complete the FPI project. 


Strategic Planning (Steps 1-4) 


1. Secure Executive Commitment for Functional Process Improvement Project 
-Conduct executive briefings 
- Concents and principles of FPI 
- DoD policy and requirements 
- Functional management process (DoD 8020.1-M, Ch 2) 
- FP] \tanagement Framework 
- Intenced expected benefits 
- Proje..t management considerations 
-Arrange site visits to organizations committed to TQM/FPI 
-Develop Charter defining scope and extent of project 
-Secure explicit commitment to launch project 
2. Confirm/Define Functional Mission 
-identify higher authority mandates/constraints 
- Review DoD relevant policy 
- Review applicable DoD directives (8000 series) 
- Review DMRD requirements/constraints 
-Idenufy current resource availability 
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-Develop statement of values and beliefs 
-Develop mission statement 
-Test mission statement for consistency and efficacy 
- Mission statement is consistent with higher authority mandates/constraints 
- Mission statement can be accomplished with current resource availability 
- Mission statement embodies stated values and beliefs 
3. Develop Strategic Pla:: 
-Idenufy functional Customers 
- External 
- Internal 
-Establish critical customer requirements and needs 
- Analysis of current service levels 
- Customer surveys and interviews 
- Value-chain analysis (customer products and services) 
-Pnoritized customer requirements and needs 
-Identify/rank current and potential competitors (alternative sources) 
-Test customer requirements and needs against mission statement 
-Resolve mission/customer requirements and needs inconsistencies 
-Develop pnonitized list of customer requirements that will be met 
-Develop functional goals for satisfying customer requirements 
- Develop vision statement (Guiding Principle(s)) 
- Identify goals for key results areas 
- Customer satisfaction 
- Productivity 
- Innovation 
- Resource conservation 
- Management development and performance 
- Employee development and performance 
- Public responsibility 
- Develop critical success factors 
-Test goals states ients against mission, values and beliefs 


4. Conduct Strategic/Customer Benchmarking and Best Practices Analysis 
-Conduct Competitive analysis 
-Examine available benchmarking databases 
-Interview customers 
-Interview functional area experts 
-Research literature 
-Validate goals statements against benchmarking best practices data 
-Refine statement of goals 


Business Planning (Steps 5-8) 


5. Develop Business Plan 
-Develop measurements for each stated goal 
-Idenufy product and services features for each customer requirement 
-Develop specific objectives for satisfying customer requirements 
-Develop perfor iance targets for each objective 
-Resolve goals, udjectives and product features anomalies 
-Develop/refine quality matrices 


6. Identify, Understand ar] Document Current Business Processes 
-Conduct/valid: »: business systems planning (BSP)/Information Systems Planning (ISP) data 
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-List business processes 

-List Current organization structures 

-Develop process/organization matrix 

-Develop product feature/process matrix 
-Evaluate/analyze/prionitize relative process performance 
-Select function: process for FPI action 


7. Document the Functional Architecture 

-Document the mission of the functional area 
-Document the :mission of the subordinate functional activity(s) 
-Relate functional area and activity(s) to Enterprise Architecture 
-Describe the business process(s) (of activity) subject to process improvement 
-Identify all organizational impacts for the business process(s) 
-Establish scope of effort for improving the business process(s) 
-Identify and charter the Functional Activity Program Manager 
-Restate/revise the parameters for process improvement 

- Process objectives 

- Performance measures and methods 

- Performance targets 

- Current performance variances to targets 
-Develop the Functional Management Strategy 
-Secure OSD Principle Staff Assistant approval to proceed 


8. Initiate Functional Process Improvement Project 

-Develop project plan 
- Develop project scope 
- Develop work breakdown structure (WBS) 
- Develop organization breakdown structure (OBS) 
- Select process improvement action team (PAT) 
- Identify project resources and facilities 
- Develop resource assignment matrix (RAM) 
- Develop initial schedules 
- Deve'op initial cost estumates 

-Conduct initial ‘raining 

-Develop project execution management plan 

-Launch project 


Process Analysis [Problems/Opportunities] (Steps 9-1 3) 


9. Review, Revise or Develop AS-IS Activity Models for Selected Process 
-Model AS-IS process/activities 
-Model AS-IS activity process flow 
-Review process models 
-Update process models 
-Validate process models 


10. Review, Revise or Develop AS-IS Data Models for Selected Process 
-Model AS-IS data models 
-Review data models 
-Update data models 
-Validate data m. dels 
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11 


We 


. Perform Activity-Based Costing Study of AS-IS Process 


-Review metrics, measures and methods 
-Conduct activity-based costing 

- Analyze activities 

- Gather cost data 

- Trace costs to activities 

- Establish output measures 

- Analyze costs 
-Conduct time-line analysis 


Conduct Cost/Process Benchmarking and Best Practice Analysis with respect to AS-IS Models 
-Develop benchmarking strategy 
- Identify features, functions and services 
- Identify operating, administrative and personnel cost categories 


-Select and screen comparison companies 
-Collect data 
- Proprietary information 
- Physical observation 
- Trade data 
-Develop conclusions 
-Refine perform¢ nce targets 


13. Perform Functional Process Improvement Analysis 


-Review objectives and measures 

- Produce the "right" products and services 

- Consistency of performance 

- Timeliness and customer response 

- Appropriate cost (competitive) 

- Safety, morale, job satisfaction 

- Good citizenship (affect on other organizations) 

- Customer relationships (flexibility, accommodation) 
-Perform techniques to discover problems and improvement opportunities 

- Pareto analysis 

- Histograms 

- Cause and effect diagrams 

- Scatter diagrams 

- Statistical process control 

- Process simulation 


-Identify quick fixes 
-Conduct what-:* analysis 
-Conduct scenario analysis 
-Analyze cost divers 
- Economies of scale 
- Learning curve effects 
- Capacity utilization 
- Linkages (value-chain analysis) (overhead) 
- Interrelationships (other business processes) 
- Integration (make us buy analysis) 
- Timing (just-in-time analysis) 
- Policy (constraints, mandates) 
- Location (geographical analysis) 
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- Institutional factors (environmental considerations) 
-Analyze quality drivers 

- Inputs {data and materials) 

- Peopk: (process personnel) 

- Equiprient (machines, computers, systems) 

- Methods (procedures, rules, regulations, training) 

- Materials (supplies, tools) 


- Environment (including location) 

- Outputs (data, products and services) 

- Administrative functions 

- External agencies and higher authonty 

- Feedback (control systems, measurements) 
-Prepare Improvement Opportunity Analysis Report 
-Conduct in-progress review (IPR) 
-Make IPR changes to AS-IS models and improvement report 
-Publish AS-IS report 


Process Design/Justufication (Steps 14-21 


14. Develop Process Improvement Initiative Packages (four classes) 
-Class i: Package quick fix improvement initiatives 
-Class 2: Package improvement initiatives that have little or no impact on existing 
information systems 
-Class .. Package improvement initiatives that have major impacts on existing 
inform<tion systems 
-Class 4 Package improvement initiatives that will require new information systems 
(new technology) 

-Rank improvement initiatives within class 


15. Develop Potential High-Level To-Be Activity and Data Models 

-Develop/revise the "vision" of the To-Be environment 
-Select To-Be concept 
-Select improvement packages for high-level modeling 
-Perform high-level modeling 

- Activity models 

- Data models 

- Process models 


16. Revise Improvement Initiative Packages Based on To-Be Models 
-Develop clear statement of problem/opportunity 
-Revise improvement initiative packages based on high-level To-Be models 
-Develop assumptions and constraints 
-Determine imp’ :mentation alternatives for each selected improvement initiative package 


17. Select Initiative Package Based on Economic Analysis of Potential Alternatives 
-Perform economic analysis 
- Collec: cost/benefit data for each alternative 
- Perfozra Risk Adjusted Discounted Cash Flow (RADCF) analysis 
- Perfona sensitivity analysis 
- Docun:ent non-quantitative considerations 


177 


18. Develop Detailed To-Be Activity and Data Models Based on Selected Initiative Package 
-Develop detailed To-Be models 
- Activity models 
- Data models 
- Process models 
-Perform simulation 
-Perform functional level integration analysis 
-Document information systems support considerations 


19. Develop Preliminary Functional Economic Analysis (FEA) Decision Package 
-Summarize functional strategic plan 
-Identify functional activity performance measures and targets 
-Document activity improvement program 
-Document economic analysis of proposed improvement initiatives 


20. Develop Data Management and Technical Management Plans 
-Develop functioaal activity information systems strategy 
-Analyze data systems 
-Document recommended changes and redirection 


21 . Develop Final Functzonal Economic Analysis (FEA) Decision Package 
-Document savings, benefits and risks of selected alternatives 
-Develop project white papers 
-Develop integrated financial plan 
-Update Planning, Programming and Budgeting System (PPBS) 
-Define approval requirements 
-Obtain policy approvals 
-Obtain FEA approval 


Improvement Execution Plan (Steps 22-25) 


22. Develop Project/Action/Transition Plans 
-Develop integrated implementation plan 
-Develop new g:yals and strategies 
-Establish new performance targets 
-Develop implementation schedule 
-Determine imp!ementation resource requirements 
-Establish implementation team 
-Designate imp|.2mentation steering committee 
-Design project 1inplementation controls 


23. Conduct Executive Presentations 
-Prepare executive briefing 
-Conduct executive briefing 
-Review recommended changes to the Project/Action/Transition Plans 
-Revise Project/Action/Transition Plans 
-Produce project implementation plan 


24. Execute Approved FEA 
-Develop design specifications 
-Develop prototype/pilot 
-Manage change 
-Conduct IPR for steering committee. 
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-Produce project *xecution report 


25. Evaluate Results, Upsiate Baseline Data and Document Lessons Learned 
-Monitor industr: trends and developments 
-Evaluate results-of improvement action 
-Establish criteria for future improvement projects 
-Document lessons learned 
-Update baseline models (convert To-Be to AS-IS) 


ee 
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APPENDIX B. AS-IS PROCESS MODEL 


This appendix contains the components of the As-Is Process Model 


documentation. Table B-1 is a list of tables and figures as they appear in the appendix. 


Table B-2 





As-Is Process Model Decomposition Diagram 






As-Is Process Model Node Tree Diagram (SSDO): 
3 Levels - Provide Student Services 


Figure B-] 








As-Is Process Model Node Tree Diagram (SSD1): 
4 Levels - Obtain Customer Input 













Figure B-3 As-Is Process Model Node Tree Diagram (SSD2): 

4 Levels - Make Changes to Student’s Course Activity 
Record 

Figure B-4 As-Is Process Model Node Tree Diagram (SSD3): 
4 Levels - Grade Student’s Exams 

Figure B-5 As-Is Process Model Node Tree Diagram (SSD4): 

| 4 Levels - Process Unit Activity Reports 

Figure B-6 As-Is Process Model Node Tree Diagram (SSDS): 
4 Levels - Process Request for Material 

Figure B-7 As-Is Process Model Node Tree Diagram (SSD6): 
4 Levels - Process Requests for Registrar Action 





Table B-1. List of Tuo-Be Process Model Components. 


18] 


INSTRUCTIONS 
PROCESS PHONE CHANGE TO STUDENT'S 
INFORMATION 


PROCESS PHONE REQUEST FOR ENROLLMENT 
SSD1.1.2.2.1.1 IDENTIFY PHONE ENROLLMENT CUSTOMER 
SSpl.12 2a OBTAIN SSN OF PHONE ENROLLMENT 
CUSTOMER 


SSDs alee INPUT SSN OF PHONE ENROLLMENT CUSTOMER 


DETERMINE DESIRED COURSE OF PHONE 
ENROLLMENT CUSTOMER 
OBTAIN DESIRED COURSE NUMBER OF PHONE 
ENROLLMENT CUSTOMER 
INPUT DESIRED COURSE NUMBER OF PHONE 
ENROLLMENT CUSTOMER 
VERIFY PHONE ENROLLMENT CUSTOMER 
INFORMATION 
VALIDATE PHONE ENROLLMENT CUSTOMER 
INFORMATION 
INPUT MISSING PHONE ENROLLMENT 
CUSTOMER INFORMATION 
SSiinmo mies VALIDATE PHONE ENROLLMENT CUSTOMER 
oe MEETS COURSE PREREQUISITES 
SSDI a ENTER TRANSACTION CODE FOR PHONE 


Z ENROLLMENT 
SSDIREZ al INPUT TC-A FOR PHONE ENROLLMENT 
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Activity Number Activity Name 


UPDATE ON-LINE TRANSACTION ENROLL FILE 
WITH PHONE ENROLLMENT 
INFORMATION 
CHANGE 


S22. a1.) OBTAIN SSN OF PHONE CHANGE CUSTOMER 
Sowen. 2.2.2. 1.2 INPUT SSN OF PHONE CHANGE CUSTOMER 


Soll 2.2.2.2 DETERMINE INFORMATION TO CHANGE BY 
PHONE 


Solel. 2.2.2.2.1 PROCESS PHONE CHANGE TO STUDENT'S NAME 
(NON-ACTIVE DUTY USMC) 
S$D1.1.2.2.2.2.1.1 | OBTAIN CHANGE TO STUDENT'S NAME BY 
PHONE (NON-ACTIVE DUTY USMC) 
SSD1.1.2.2.2.2.1.2 | INPUT CHANGE TO STUDENT'S NAME BY PHONE 
(NON-ACTIVE DUTY USMC) 


ADDRESS (NON-ACTIVE DUTY USMC) 

PHONE (NON-ACTIVE DUTY USMC) 

PHONE (NON-ACTIVE DUTY USMC) 
Slit? 2.2.2.3 PROCESS PHONE CHANGE TO STUDENT'S RANK 
(NON-ACTIVE DUTY USMC) 


(NON-ACTIVE DUTY USMC) 
(NON-ACTIVE DUTY USMC) : 
CHANGE 


Seb 2.2.32) INPUT TC-D FOR CHANGE BY PHONE 


Slee 2.2.2.3.2 UPDATE ON-LINE TRANSACTION R-6 FILE WITH 
PHONE CHANGE 


PROCESS PHONE REQUEST FOR EXTENTION 


EXTENTION CUSTOMER 
EXTENTION CUSTOMER | 


Scbriminon mse INPUT DESIRED COURSE NUMBER OF PHONE 
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SP), 5 sat 





SSP 7 To 





pi EXTENTION CUSTOMER 


INFORMATION 
INFORMATION 
| INFORMATION 
MEETS COURESE PREREQUISITES 
EXTENTION CUSTOMER 


SSDI. 2.3.45 INPUT TC-E FOR PHONE EXTENTION 


ae 
PHONE EXTENTION 
DISENROLLMENT 


SSD 1TV222c45 18 | OBTAIN SSN OF PHONE DISENROLLMENT 
CUSTOMER 


SSD1.1.2.2.4.1.2 | INPUT SSN OF PHONE DISENROLLMENT 
CUSTOMER 


DISENROLLMENT CUSTOMER 
DISENROLLMENT CUSTOMER 
DISENROLLMENT CUSTOMER 
INFORMATION 

INFORMATION 

CUSTOMER INFORMATION 
MEETS COURSE PREREQUISITES 
DISENROLLMENT 


SS$D1.1.2.2.4.4,] INPUT TC-H FOR PHONE DISENROLLMENT 


PHONE DISENROLLMENT 
ENROLLMENT 
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SSD11.2.2.5.1 IDENTIFY PHONE RE-ENROLLMENT CUSTOMER 


CUSTOMER 
CUSTOMER 






ENROLLMENT CUSTOMER 
OBTAIN DESIRED COURSE NUMBER OF PHONE 
RE-ENROLLMENT CUSTOMER 
| ENROLLMENT CUSTOMER | P. 


Spel 75 3 | VERIFY PHONE RE-ENROLLMENT CUSTOMER 





INFORMATION 


INFORMATION 

CUSTOMER INFORMATION 
MEETS COURSE PREREQUISITES 
ENROLLMENT 
CUSTOMER 
WITH PHONE RE-ENROLLMENT 





SSD1.1.2.3.1 DETERMINE MATERIAL PHONE CUSTOMER 
NEEDS 
SSD1.1.2.3.1.2 VALIDATE PHONE CUSTOMER'S MATERIAL 
REQUEST 


Soe 2.3.2 PROCESS STANDARD REQUESTS FOR MATERIAL 
FOR PHONE CUSTOMER 


Se Dia 23.2.1 VALIDATE PHONE CUSTOMER'S REQUEST 


REQUESTED BY PHONE 
REQUESTED BY PHONE 

ENTER TC-I FOR PHONE REQUEST FOR 
DUPLICATE EXAM 


SSD1.1.2.3 2.3.2 | ENTER TC-P FOR PHONE REQUEST FOR 
; DUPLICATE COURSE/PROGRAM 


Table B-2. As-Is Proc ess Model Decomposition Diagram. 
185 


Activity Number Activity Name 


ENTER TC-T FOR PHONE REQUEST FOR 
INDIVIDUAL GENERIC DP-37 
SSD1.1.2.3.2.3.4 ENTER TC-Y FOR PHONE REQUEST FOR 
DUPLICATE DIPLOMA/COMPLETION 


CERTIFICATE 


PREPARE "REQUEST FOR MATERIAL" FORM FOR 
PHONE CUSTOMER 

OBTAIN BLANK "REQUEST FOR MATERIAL" 
FORM 

WRITE PHONE CUSTOMER'S NAME ON 
"REQUEST FOR MATERIAL" FORM 

WRITE PHONE CUSTOMER'S SSN ON "REQUEST 
FOR MATERIAL" FORM 





SSD1.1.2.3.34 WRITE PHONE CUSTOMER'S ADDRESS ON 
: “REQUEST FOR MATERIAL" FORM 
SoD TZ 3) WRITE PHONE CUSTOMER'S DESIRED ITEM 





NAME ON "REQUEST FOR MATERIAL" FORM 
SSD1.1.2.3.3.6 WRITE PHONE CUSTOMER'S DESIRED QUANTITY 
— ae ON "REQUEST FOR MATERIAL” FORM 
PREPARE “OFF-LINE REQUEST" FORM FOR 
PHONE CUSTOMER 


| 99D1.1.2.3.4.1 OBTAIN BLANK "OFF-LINE REQUEST" FORM 


SSD1.1.2.3.4.2 WRITE PHONE CUSTOMER'S NAME ON "OFF-LINE 
REQUEST" FORM 


SSD1.1.2.3.4.3 | WRITE PHONE CUSTOMER'S SSN ON "OFF-LINE 





REQUEST" FORM 


SSD1.1.2.3.4.4 WRITE PHONE CUSTOMER'S ADDRESS ON "OFF- 
LINE REQUEST" FORM 


SSD1.1.23.4.5 WRITE PHONE CUSTOMER'S ITEM NAME ON 
"OFF-LINE REQUEST" FORM 
SSD1.1.2.3.4.6 WRITE PHONE CUSTOMER'S DESIRED QUANTITY 
2 ON "OFF-LINE REQUEST" FORM 

SSD1.2 | 
SSD1.2.1 
SSD1.2.1.1 
SSD1.2.1.2 
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Activity Number Activity Name 


SEGREGATE WRITTEN REQUEST FOR STATUS 
SEGREGATE WRITTEN REQUEST FOR CHANGE 
TO CUSTOMER STATUS 
SSD1.2.3.3 SEGREGATE WRITTEN CHANGE TO CUSTOMER 


SEGREGATE WRITTEN REQUEST FOR MATERIAL 

SORT INCOMING E-MAIL 

PRINT E-MAIL MESSAGES 

SEGREGATE E-MAIL REQUEST FOR STATUS / 

SEGREGATE E-MAIL REQUEST FOR CHANGE TO 
CUSTOMER STATUS 

SEGREGATE E-MAIL REQUEST FOR MATERIAL 


SSD1.3.5 SEGREGATE E-MAIL UAR RESPONSE 
S5D1.3.6 PROCESS INDIVIDUAL E-MAIL RECEIVED 


PROCESS WALK-IN CUSTOMERS 


© 





SSD1.4.1 
SSD1.4.1.1 
CUSTOMER STATUS / INFORMATION 
SSD2 MAKE CHANGES TO STUDENT'S COURSE 
ACTIVITY RECORD 
| SSD2.1.1 | IDENTIFY ENROLLMENT CUSTOMER 
aeeSSD2 Ieee ees WOBPAIN'SSN OF ENROLUMENT CUSTOMER | 
INPUT SSN OF ENROLLMENT CUSTOMER 


SoZ. 2 DETERMINE TYPE OF ENROLLMENT 


SoZ 2 | PROCESS REQUEST FOR REGULAR 
ENROLLMENT 

VERIFY INFORMATION OF REGULAR 
ENROLLMENT CUSTOMER 

VALIDATE INFORMATION OF REGULAR 
ENROLLMENT CUSTOMER 

INPUT MISSING INFORMATION OF REGULAR 
ENROLLMENT CUSTOMER 


Somo2. 1. 2.1.1.3 VALIDATE REGULAR ENROLLMENT CUSTOMER 
MEETS COURSE PREREQUISITES 
S221? DETERMINE COURSE OF REGULAR 
ENROLLMENT CUSTOMER 
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S221. 1 


SoZ 21a) | 


Sew el 21.1.2 





Activit Number Activity Name 


SS D2 Zale 


OBTAIN COURSE OF REGULAR ENROLLMENT 
CUSTOMER 

INPUT COURSE CODE OF REGULAR 
ENROLLMENT CUSTOMER 

PROCESS REQUEST FOR BULK ENROLLMENT 
VERIFY INFORMATION OF BULK ENROLLMENT 
CUSTOMER 

VALIDATE INFORMATION OF BULK 
ENROLLMENT CUSTOMER 


INPUT MISSING INFORMATION OF BULK 
ENROLLMENT CUSTOMER 

VALIDATE BULK ENROLLMENT CUSTOMER 
MEETS COURSE PREREQUISITES 

DETERMINE COURSE OF BULK ENROLLMENT 
CUSTOMER 

OBTAIN COURSE OF BULK ENROLLMENT 
CUSTOMER 

INPUT COURSE OF BULK ENROLLMENT 

| CUSTOMER 


SS$SD2.1.2.3 PROCESS REQUEST FOR ADMINISTRATIVE 
ENROLLMENT 

VERIFY INFORMATION OF ADMINISTRATIVE 
ENROLLMENT CUSTOMER 

VALIDATE INFORMATION OF ADMINISTRATIVE 
ENROLLMENT CUSTOMER 

INPUT MISSING INFORMATION OF 
ADMINISTRATIVE ENROLLMENT CUSTOMER 


VALIDATE ADMINISTRATIVE ENROLLMENT 
CUSTOMER MEETS COURSE PREREQUISITES 

DETERMINE COURSE OF ADMINISTRATIVE 
ENROLLMENT CUSTOMER 

OBTAIN COURSE OF ADMINISTRATIVE 
ENROLLMENT CUSTOMER 

INPUT COURSE CODE OF ADMINISTRATIVE 
ENROLLMENT CUSTOMER 

PROCESS REQUEST FOR RE-ENROLLMENT 


SSD2.1.2.4.1 VERIFY INFORMATION OF RE-ENROLLMENT 
CUSTOMER 


99 D2.1.2.4.1.1 VALIDATE INFORMATION OF RE-ENROLLMENT 
CUSTOMER 

§9D2.1.2.4.1.2 INPUT MISSING INFORMATION OF RE- 
ENROLLMENT CUSTOMER 


SoZ eZee 2 


SoD2 nz 
SoD2 e272! 


SoD 2 alee 





SODA ae 


So ID2 eZ. sae! 


S912. Zea 
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Activity Number Activity Name 


COURSE PREREQUISITES 
CUSTOMER 


$$D2.1.2.4.2.1 OBTAIN COURSE OF RE-ENROLLMENT 
CUSTOMER 
SS D2.1.2.4.2.2 INPUT COURSE OF RE-ENROLLMENT CUSTOMER 


ENROLLMENT 
ENROLLMENT CUSTOMER 
ENROLLMENT CUSTOMER 
ENROLLMENT CUSTOMER 
VALIDATE SPECIAL RE-ENROLLMENT 
CUSTOMER MEETS COURSE PREREQUISITES 
ENROLLMENT CUSTOMER 
OBTAIN COURSE OF SPECIAL RE-ENROLLMENT 
CUSTOMER 








SSID201,.2:5.2.2 INPUT COURSE OF SPECIAL RE-ENROLLMENT 
CUSTOMER 
SSD2.1.3.2 
‘i ENROLLMENT 
SS$D2.1.3.4 
SSb2aia'5 
UPDATE ON-LINE TRANSACTION ENROLL FILE 
WITH ENROLLMENT 
INFORMATION 
OBTAIN CHANGE TO STUDENT'S NAME 
INPUT CHANGE TO STUDENT'S NAME 










ee PROCESS CHANGE TO STUDENT'S RANK 
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Activity Number Activity Name 


SS22) 2:27 1 OBTAIN CHANGE TO STUDENT'S RANK 


SS D222 INPUT CHANGE TO STUDENT'S RANK 


$S8D2.2.2.3 PROCESS CHANGE TO SERVICE COMPONENT 
OBTAIN CHANGE TO STUDENT'S SERVICE 
COMPONENT 


pis D2 2 INPUT CHANGE TO STUDENT'S SERVICE 
COMPONENT 


SSD2.2.2.4 PROCESS CHANGE TO SERVICE STATUS 


OBTAIN CHANGE TO STUDENT'S SERVICE 
STATUS 

INPUT CHANGE TO STUDENT'S SERVICE 

STATUS 


S01 212.2238 





PROCESS CHANGE TO STUDENT'S ADDRESS 
OBTAIN CHANGE TO STUDENT'S ADDRESS 
INPUT CHANGE TO STUDENT'S ADDRESS 
ENTER TRANSACTION CODE FOR CHANGE 


So D2 INPUT TC-D FOR CHANGE TO STUDENT'S DATA 


SOID2Z: 2-362 UPDATE ON-LINE TRANSACTION R-6 FILE WITH 
CHANGE 


so D2'3 PROCESS REQUEST FOR ADMINISTRATIVE 
ACTION 

PROCESS REQUEST FOR EXTENSION 
IDENTIFY EXTENSION STUDENT 

Sow2.3 1 Tel OBTAIN SSN OF EXTENSION STUDENT 


Sle INPUT SSN OF EXTENSION STUDENT 
SDDZ ae OBTAIN NAME OF EXTENSION STUDENT 
$$D2.3.1.1.4 INPUT NAME OF EXTENSION STUDENT 


SSZr351 


So DZ 23a 





SSD 22 VERIFY INFORMATION OF EXTENSION STUDENT 
Ss2enom VALIDATE INFORMATION OF EXTENSION 
STUDENT 


STUDENT 
PREREQUISITES 


SSD2.3.1.4.2 UPDATE ON-LINE TRANSACTION R-6 FILE WITH 
EXTENSION 
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Activity Name 

PROCESS REQUEST FOR DISENROLLMENT 
IDENTIFY DISENROLLMENT STUDENT 
OBTAIN SSN OF DISENROLLMENT STUDENT 


po D2 372.2 DETERMINE COURSE OF DISENROLLMENT 
STUDENT 


OBTAIN COURSE OF DISENROLLMENT STUDENT 
INPUT COURSE OF DISENROLLMENT STUDENT 
VERIFY INFORMATION OF DISENROLLMENT 
STUDENT 

| VALIDATE INFORMATION ABOUT 
DISENROLLMENT CUSTOMER 
INPUT MISSING INFORMATION ABOUT 
DISENROLLMENT CUSTOMER 


VALIDATE DISENROLLMENT CUSTOMER MEETS 
PREREQUISITES 

ENTER TRANSACTION CODE FOR 
DISENROLLMENT 


SiOz 2 4. | INPUT TC-H FOR DISENROLLMENT 


SISO 25-22 INPUT SSN OF DISENROLLMENT STUDENT 


Pow 22.2.2 
poD2:3%25 


ped 2ese2 ook 


S51 25:2.3.2 





So D2 3724.2 UPDATE ON-LINE TRANSACTION R-6 FILE WITH 
DISENROLLMENT 


PROCESS EXAM ISSUE 
IDENTIFY STUDENT FOR EXAM ISSUE 
$$D2:3.3.1.3 


SSD2.3.3.1.4 











INPUT NAME OF STUDENT FOR EXAM ISSUE 


sob? .3.3.2 IDENTIFY COURSE FOR EXAM ISSUE 
SD 2-3. 5:2+1 OBTAIN COURSE FOR EXAM ISSUE 
95D2.3.3.2.2 INPUT COURSE CODE FOR EXAM ISSUE 


ISSUE 
EXAM ISSUE 
EXAM ISSUE “ 








-§SD2.3.3.3.3 VALIDATE STUDENT MEETS PREREQUISITES 
FOR EXAM ISSUE 
SS$D2.3.3.4 ENTER TRANSACTION CODE FOR EXAM ISSUE 


§5D2.3.3.4.1 INPUT TC-I FOR EXAM ISSUE 
SD Zine .4.2 UPDATE ON-LINE TRANSACTION R-6 FILE FOR 
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EE Ee Se 
sess lee 
$$D2.3.4.1.2 INPUT SSN OF CUSTOMER FOR PME ADMIN 
a ae 
SSD2.3.4.3 VERIFY CUSTOMER INFORMATION FOR PME 
eee 
FOR PME ADMIN CREDIT 
$3$D2.3.4.3.2 INPUT MISSING INFORMATION ABOUT 
MEETS PREREQUISITES 


SSD2.3.4.4 - ENTER TRANSACTION CODE FOR ADMIN CREDIT 
FONEME Awe. ‘ = 
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Figure B-3. As-Is Process Model Node Tree Diagram (SSD2). 
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APPENDIX C. TO-BE PROCESS MODEL 


This appendix contains the components of the To-Be Process Model 


documentation. Table C-1 is a list of tables and figures as they appear in the appendix. 


Table C-2 To-Be Process Model Decomposition Diagram 
Table C-3 To-Be Activity Dictionary 


Table C-4 








To-Be Arrow Dictionary 






To-Be Process Model Node Tree Diagram (TO) 
All Levels - Student Service Support 






To-Be Process Model Context Diagram (T-0) 













Figure C-3 - C-37 To-Be Process Model IDEFO Diagrams 


Figure C-38 To-Be Process Model CRUD Matrix 
Figure C-39 To-Be Process Model Clustered CR Matrix 


Table C-1. List of To-Be Process Model Components. 
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Table C-2. To-Be Pracess Model Decomposition Diagram. 
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Activity Name 
DETERMINE COMPONENT SHIP STATUS 
DETERMINE JOB AID SHIP STATUS 
DETERMINE CERTIFICATION SHIP STATUS 
DETERMINE UNIT MATERIAL SHIP STATUS 
CHANGE STUDENT INFORMATION 
PROCESS NAME CHANGE 
PROCESS SSN CHANGE 
PROCESS GRADE CHANGE 
PROCESS SERVICE COMPONENT CHANGE 
PROCESS SERVICE STATUS CHANGE 
PROCESS ADDRESS CHANGE 
PROCESS ADMINISTRATIVE ACTION 

le 41 DETERMINE TYPE OF ADMIN ACTION 
VALIDATE ADMIN ACTION 
EVALUATE ENROLLMENT STATUS 
ie EVALUATE EXAM ISSUE STATUS 
143 EVALUATE COURSE HISTORY 
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1 GRADING 
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| 











TSii1.3 


Table C-2. To-Be Process Model Decomposition Diagram. 
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Activity Name 

EDIT DP-37 DATA 

EDIT PRE-SLUGGED DP-37 DATA 

EDIT GENERIC DP-37 DATA 

ANALYZE DP-37 DATA 

EVALUATE EXAM 

COMPARE STUDENT RECORD HISTORY 
PROCESS OPSCAN ERRORS 

PRODUCE OPSCAN ERROR REPORT 
CORRECT ERRONEOUS DP-37 


Activity Number 

di si3i). 
332) 
T3302 

T382 
Sora 
Sse 

34 
eae 
i seae2 


FIND ERRONEOUS DP-37 
REGISTRAR SERVICING 
ISSUE DIPLOMA 


Table C-2. To-Be Process Model Decomposition Diagram. 


Activity Name Activity Definition 


ANALYZE DP-37 DATA 






This activity represents the process of 
retrieving the DP-37 data and grading it to 
determine if the examination passed. 
This activity represents the processes that 
enable the MCI clerk to change student 
information. Information that can be 
changed includes name, rank, SSN, address, 
service status and service component. 
COMPARE STUDENT RECORD If the student passes the exam, the student 
HISTORY course record is updated on the database to 
reflect a completed course. If the completed 
course 1s a PME course, the students 
records are read to see if the student has 
completed all of the sub-courses for that 
PME. If all of the sub-courses are complete, 
the PME record is updated to reflect a 
completed Program. The record is moved 
to the history file and a completion 
certificate and diploma will be generated. 
CORRECT ERRONEOUS DP-37 This activity represents the process of 
correcting the file containing all the errors 
generated when editing and grading the DP- 
37s. This should be done on-screen with 
direct access to student and course 
information. 











CHANGE STUDENT INFORMATION 








CUSTOMER SERVICING This business function represents the 
processes required to provide direct support 
to customers by receiving the input, 
distributing it for processing, and 
responding to the customer, when 
applicable. 


DETERMINE CERTIFICATION SHIP This activity identifies the shipping status of 
STATUS specified material in response to a request 
for completion certificate shipping status. 

DETERMINE CERTIFICATION Given the requestor is enrolled in a course 

STATUS or program, this activity determines if a 
completion certificate has been generated 
and issued to the student. The status of the 
student's completion certification is 
returned, 1.e. issue date and mauled date 
when capable. 
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Activity Name 
DETERMINE COMPONENT SHIP This activity identifies the shipping status of 
STATUS specified material in response to a request 
for component materials shipping status. 
This activity identifies the shipping status of 
specified material in response to a request 
for course or program materials status. 
Given the requestor is enrolled in a course 
or program, this activity determines the 
Status of the student's progress in that 
course or program, 1.e. the number of 
lessons completed (if required to be 
submitted). 
DETERMINE ENROLLMENT STATUS _ | This activity determines if the requestor is 
enrolled in the course identified and 
determines the status of that enrollment. 
Given the requestor is enrolled in a course 
or program, this activity determines if the 
exam has been issued, graded, or being 
processed from the Error Listing. The 
Status of the student's progress or status on 
the exam is produced. 
This activity identifies the shipping status of 
specified material in response to a request 
for job aid materials shipping status. 
DETERMINE MATERIAL This activity identifies the on hand 
AVAILABILITY © availability of material for delivery given the 
type of material requested. 
DETERMINE PROGRESS OF This activity provides the status of progress 
RESEARCH researching information for a requestor's 
transcript. 





















DETERMINE COURSE MATERIAL 
STATUS 















DETERMINE COURSE STATUS 








DETERMINE EXAMINATION STATUS 




















DETERMINE JOB AID SHIP STATUS 















DETERMINE TRANSCRIPT SHIP DATE | This activity provides the shipping status of 
a produced transcript in response to a 
transcript request. 





DETERMINE TYPE OF ADMIN 
ACTION 


This activity distinguishes what type of 
administrative action is requested, 1.e. 

disenrollment or administrative credit for 
PME. 
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DETERMINE TYPE OF ENROLLMENT | This activity represents the process of 
determining the type of enrollment which 
applies to the requestor for the specific 
enrollment. An enrollment can be either 
regular or administrative. An administrative 
enrollment will not issue materials but 
registers the requestor into the database as 
a Student. 
This activity identifies the shipping status of 
specified material in response to a request 
for unit materials shipping status. 


loading and editing the DP-37 data. 

EDIT GENERIC DP-37 DATA This activity represents the process of 
editing the file with data from the generic 
DP-37s. It will convert any numeric data 
from answers to alpha-numeric data and 
ensure the required data was scanned 
properly. It will also draw student and 
course information from the MCIAIS 
database. This is where proctoring rules for 
courses 3520 and 3521 are enforced. All 
good records build a file to be graded. All 
failed records build a file for the Error 
Listing. 






















DETERMINE UNIT MATERIAL SHIP 
STATUS 





EDIT PRE-SLUGGED DP-37 DATA This activity represents the process of 


editing the file with data from the pre- 
Slugged DP-37s. It will convert any numeric 
data from answers to alpha-numeric data 
and ensure the required data was scanned 
properly. All good records build a file to be 
graded. All failed records build a file for the 
Error Listing. 

ENTER HAND GRADED EXAMS This activity represents the process of 

SCORES entering the scores from hand graded exams 
into a file for evaluation. 

ENTER SCORES FOR PME EXAMS This activity represents the process of 
entering the scores from PME exams into a 
file for evaluation. 
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Activity Definition 


This activity evaluates the student's course 
history to determine if previous MCI 
products completed are sufficient to 
provide the requested PME administrative 
credit. For example, if the student had been 
enrolled and completed several courses in a 
previous version of the Command and Staff 
Program, the student may be eligible for 
credit in part of the current Command and 
Staff Program. 
Process used to determine if the customer 
meets Course or Program pre-requisites 
based on prior completion of other MCI 
course, MC] Programs, or Resident 
Programs attended. 
This activity evaluates the enrollment status 
of the student to determine if student can be 
disenrolled or to provide credit to a course 
the student is enrolled in. 
This activity determines the student's exam 
score and whether that score was sufficient 
to pass the course. 
EVALUATE EXAM [ISSUE STATUS This activity evaluates if the student's 
record contains an examination which has 
been received and graded. Administrative 
credit would not be necessary if the student 
had completed the course. A course 
completion would be issued instead of 
disenrollment if the student passed the 
exam. 
EVALUATE FOREIGN MILITARY This activity represents the processes 
STATUS required to validate the requestor's 


Activity Name : 
EVALUATE COURSE HISTORY 



















EVALUATE COURSE/PROGRAM 
HISTORY 












EVALUATE ENROLLMENT STATUS 

















EVALUATE EXAM 






eligibility to be issued requested matenals 
based on the status as a member of a 


EVALUATE GRAD: Process used to determine if the requestor 
meets Course or Program pre-requisites 
based on grade. 

EVALUATE MILITASRY/DOD STATUS | This activity represents the processes 
required to validate the requestor's 
eligibility to be issued requested materials 
based on the status as a military or DoD 
employee. 
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EVALUATE OTHER COURSE CREDIT | This activity evaluates course work 
completed from other similar non-MCI 
Courses or programs like might provide 
simular areas of study credit, i.e. War 
College, Armed Forces Staff College, etc. 
EVALUATE SERVICE COMPONENT Process used to determine if the requestor 
meets Course or Program pre-requisites 
based on service component. 
This activity represents the processes 
required to validate the requestor's 
eligibility to be issued requested materials 
based on the status as a student. 
EVALUATE UNIT REP STATUS This activity represents the processes 
required to validate the requestor's 
eligibility to be issued requested materials 
based on the status as a unit training 
representative. 
This activity represents the manual process 
of filing the scanned DP-37s into a file after 
successful scanning until the OpScan Error 
[S| DECCESSCG Arm Mal: oT 
| This activity represents the manual process 
of filing the scanned DP-37s into a file after 
successful scanning until the OpScan Error 
Listing is processed. 
FIND ERRONEOUS DP-37 This activity represents the process of 
correcting the file containing all the 
remaining errors, after on-line processing, 
generated when editing and grading the DP- 
37s. This requires viewing the original DP- 
37 submitted. 
This activity represents the manual process 
of forwarding the unscannable DP-37s to 
the grading section for hand-grading. 
FORWARD UNSCANNED PS DP-37s This activity represents the manual process 
of forwarding the unscannable DP-37s to 
the grading section for hand-grading. 
This business function represents the 
processes required to grade and record 
student examinations in the database. 



















EVALUATE STUDENT STATUS 











FILE SCANNED GENERIC DP-37s 












FILE SCANNED PRE-SLUGGED DP-37s 








FORWARD UNSCANNED GEN DP-37s 









GRADING 
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Activity Name j Activity Definition 
HAND GRADE NC?tv-SCANNABLE DP-_ | Process of hand grading DP-37s either 
57S rejected by the Scantron or received as 
unscannable (photo copy or mutilated). 
Involves locating course number and exam 
version number in binder and extracting key 
for hand grading exam, then manually 
checking for passing score and entering 
pass/fail information in MCIAIS. 


Enter the requestor's Course completion 
date from research. 

Enter the requestor's Course number from 
research. 


INPUT COURSE TITLE Enter the requestor's Course title from 
research. 

Enter the requestor's Course enrollment 
date from research. 

INPUT GRADE PERCENT Enter the requestor's grade received for 
completing Course from research. 
Enter the requestor's address. 

Enter the requestor's dates of service. 











INPUT ENROLLMENT DATE 


INPUT REQUESTCE'S ADDRESS 
INPUT REQUESTOR'S DATES OF 
SERVICE 


INPUT REQUESTOR'S NAME Enter the requestor's name. 
INPUT REQUESTOR'S SSN Enter the requestor's SSN. 


INPUT STUDY HOURS Enter the requestor's number of study hours 
for completing Course from research. 









This activity represents the processes 
required to produce and issue diplomas to 
student's completing the required Courses 
for MCI Programs. This activity also 
applies to requests for duplicate diplomas. 
This activity represents the process of 
preparing a transcript and the form letter 
reply in response to a transcript request. 
This activity represents the processes of 
receiving input from customers and the 
subsequent distribution of the input for 
processing. Input can be received by phone, 
walk-in, U.S. Mail, or electronic mail (also 
considered as naval message). 
This activity represents the process of 
packaging the diploma into an envelope for 
mailing. 







ISSUE DIPLOMA 


ISSUE TRANSCRIPT 




















OBTAIN CUSTOMER INPUT 


















PACKAGE DIPLOMA FOR MAILING 
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PACKAGE TRANSCRIPT FOR This activity represents the processes 
MAILING required to package and deliver a student's 
transcript in response to a transcript 
request. 
This activity represents the generation of a 
Unit Activity Report used to reconcile 
student activity with a Marine Corp Unit 
and the unit commander with unit MCI 
participation summary information. 



















PREPARE UARs 







PRINT DIPLOMAS This activity represents the process of 
printing diplomas to be issued or re-issued. 
PRINT TRANSCRIFT This activity represents the process of 
preparing a transcript and the form letter 
reply in response to a transcript request. 


PROCESS GENERIC DP-37s This activity represents the processes 
required to build input files with data from 
the student exams that have not been pre- 
Slugged with student and course 
information for evaluation. 


PROCESS ADDRESS CHANGE This activity represents the process of 
changing a student's address. 


PROCESS ADMINISTRATIVE ACTION | This activity represents the processes of 
completing administrative actions such as, 
disenrollment and administrative credit for 
Professional Military Education Courses. 
PROCESS COURSE STATUS REQUEST | This activity represents the processes 
required to provide a student the status on 
the courses and/or programs in which 















currently enrolled. 

PROCESS DP-37s This activity represenis the processes 
required to build files with data from the 
student exams (DP-37) for evaluation. 
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PROCESS ENROLLMENT This activity refers to the enrollment of a 
requestor into an MCI Course or MCI 
Program. The processes require identifying 
the requestor, the requested 
course/program, and determining eligibility 
for enrollment based on course/program 
pre-requisites. Once enrolled, a requestor 1s 
considered a Student. There are two types 
of enrollments; Regular and Administrative. 
The enrollment action generates the 
necessary flags to initiate delivery of course 
program materials. 


PROCESS GRADE CHANGE This activity represents the process of 
changing a student's rank. 


PROCESS HAND GRADED EXAMS This activity represents the process of 
manually hand grading examinations (DP- 
37s) which could not be scanned, entering 
the scores for those exams, and entering the 
scores for PME examinations/essays. 
This activity represents the processing of 
incoming phone calls by an MCI Immediate 
Assist Clerk. This includes such activities as 
processing an enrollment, providing status 
and general information about MCI 
Products (Job Aids, Courses and 

| Programs), changing student information, 
administrative action (disenrolilment and 
PME credit), and issuing material in 
response to a request. 
This activity identifies the shipping status of 
specified material in response to a shipping 
status request for component, job aid, 








































PROCESS INCOMING PHONE CALLS 


















PROCESS MATERIAL STATUS 
REQUEST 










PROCESS OPSCAN ERRORS 





This activity represents the processes 
performed to generate the Opscan Error 
Report file and correcting the errors on the 
file, both on-screen and using the orginal 
DP-37 if necessa 
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PROCESS PRE-SLUGGED DP-37s This activity represents the processes 
required to build files with data from the 
Student exams that have been pre-slugged 
with student and course information for 
evaluation. 

This activity represents the processes for 

filling customer requests for material such 

as, courses, programs, components of 

courses or programs, job aids and Training 

NCO material. 












PROCESS REQUEST FOR MATERIAL 








CHANGE changing a student's service component. 
changing a student's service status. 
changing a student's SSN. 


PROCESS STATUS REQUEST This activity represents the processes 
performed to provide student's with status 


for their requests. Information is provided 


on a Student's status within a Course or 
Program, status on transcript preparation, 
and status on material requests. 
This activity provides the status of progress 
researching information for a requestor's 
transcript and the shipping status of a 
produced transcript in response to a 
transcript request. 
PROCESS WALK-IN CUSTOMERS This activity represents the processing of a 
walk-in customer by an MCI Immediate 
Assist Clerk. This includes such activities as | 
processing an enrollment, providing status 
| and general information about MCI 
Products (Job Aids, Courses and 
Programs), changing student information, 
administrative action (disenrollment and 
PME credit), and issuing material in 
response to a request. 










PROCESS TRANSCRIPT STATUS 
REQUEST 
















This activity represents the activities 
required to generate the file containing all 
the errors generated when editing and 

erading the DP-37s. 


PRODUCE OPSCAN ERROR REPORT 
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PROVIDE UNIT ACTIVITY SERVICES | This activity represents the processes of 
receiving input from Unit Activity 
customers (Training NCOs) and the 
subsequent processes to facilitate 
reconciliation with the Unit as a customer. 
Input can be received by phone, walk-in, 
U.S. Mail, or electronic mail (also 
considered as naval message). 
Reconciliation is initiated with a periodic 
Unit Activity Report. 
This activity represents the referral of 
transcript customer to HQMC for transcript 
information prior to Jan 1979. 
REGISTRAR SERVICING This business function represents the 
processes required to issue diplomas and 
research, produce and deliver transcripts. 
RESEARCH TRANSCRIPT This activity represents the processes 
INFORMATION performed to research and input 
information required to produce a 

e | transcript. | 

RUN GRADING PROGRAM This activity represents the process of 
grading the input files containing the 
scanned data from the student 
examinations. 

SCAN GENERIC D.?-37s This activity represents the processes of 
loading the OpScanner with Generic DP- 
37s to get the student's exam data and 
format that data into a file for the grading 


















REFER CUSTOMER TO HQMC 





SCAN PRE-SLUGGED DP-37s This activity represents the processes of 
loading the OpScanner with Pre-Slugged 
DP-37s to get the student's exam data and 
format that data into a file for the grading 


SEARCH ACTIVE FILES This activity represents the process of 
searching the active records of MCIAIS for 
transcript customer's course completion 
history. 

SEARCH ARCHIVE FILES This activity represents the process of 
searching the archived records of MCIAIS 





for transcript customer's course completion 
histo 
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Activity Name Activity Definition 


This activity searches archive records on 
microfiche for transcript customer's course 


SEARCH MICROFICHE 


SEARCH ON-LINE DATA 


completion history. 
This activity searches MCIAIS active and 
archive records for transcript customer's 









SEGREGATE E-MAIL MATERIAL 
REQUESTS 






SEGREGATE E-MAIL STATUS 
CHANGES 


SEGREGATE E-MAIL STATUS 
REQUEST 






course completion history. 

This activity represents the redistribution of 
electronic mail requesting material to the 
Processing Section mail-box for material 
requests. 
This activity represents the redistribution of 
electronic mail requesting a change toa 
requestor's status to the Processing Section 
mail-box for status change requests. 
Changing status includes enrolling, 
changing personal information, disenrolling, 
or completion of a course or part of a 
program with administrative credit. 
This activity represents the redistribution of 
electronic mail requesting status to the 
Processing Section mail-box for status 


































SEGREGATE E-MAIL UAR RESPONSE 





SEGREGATE ESSAY EXAMS 


SEGREGATE FEEDBACK FORMS 


SEGREGATE GENERIC DP-37s 
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This activity represents the redistribution of 
electronic mail Unit Activity Reports to the 
Unit Activity Report Section mail-box. 
| This activity represents the process of 
separating PME essay exams and forwards 
them to PMED for grading. 
The process removes PMED and OSD feed 
back forms from the student course input 
received and forwards them to PMED or 
OSD for processing. 
This manual process segregates exams and 
lessons which have not been pre-formatted 
with user information for the specific course 
or program (generic DP-37s) and forwards 
| them to be graded. 


a a 
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SEGREGATE MAILED INQUIRIES This process receives Mailed Customer 
Inquiries and forwards the Input to 
subsequent activities for processing. The 
Mailed Customer Inquiries consist of 
requests for enrollment, requests for 
missing course materials, missing 
diplomas/completion certificates, requests 
for transcripts, requests for disenrollment, 
requests for status of student progress, 
requests for course catalogs, requests for 
information about courses in general, 
change address information on individual, 
from either a student or a unit 
representative. The requests for Transcripts 
are forwarded to the Registrar Section; the 
requests for Completion Certificates, 
Diplomas, replacement materials, 
enrollment, disenrollment, and changes to 
information are forwarded to the Processing 
Section. 
SEGREGATE PERSONAL E-MAIL This activity represents the redistribution of 


























electronic mail to a specific individual's 
mail-box for processing. 


SEGREGATE PRE-SLUGGED DP-37s This manual process segregates exams and 
lessons which have been pre-formatted with 
user information peculiar to the specific 
course or program (Pre-Slugged DP-37s) 
and forwards them to be graded. 


SEGREGATE STUDENT COURSE This activity processes Student Course 
INPUT Input and forwarded to subsequent 
activities. The Student Course Input should 


include a completed lesson or course 
examination (DP-37), or a copy of a 
completed DP-37, and a feedback sheet. 
The feedback sheet is forwarded to either 
PMED or OSD according to the 
course/lesson completed. The DP-37s are 
segregated by type (Generic or Pre- 
Slugged) and forwarded to the grading 
section. 
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SEGREGATE UNIT INPUT This activity represents the process of 
receiving Unit Input and forwarding the 
Input to the UAR section for processing. 
The Unit Input should include a Unit 
Activity Report (UAR) or request for Unit 
support material. UAR input includes 
requests for, and submission of, information 
on behalf of a Student. 

SORT INCOMING E-MAIL This activity represents the processes 
performed with incoming electronic mail. 
This includes distribution for processing 
within SSD and forwarding correspondence 
to other personnel, divisions, and 
departments within MCI. 








SORT INCOMING U.S. MAIL This activity represents the processes 
performed with incoming mau. This 
includes segregation and distribution for 
processing within SSD and forwarding 
correspondence to other departments within 
MCI, 


STUDENT ACTIVITY SERVICING This business function represents the 
processes required to maintain a student's 
course activity record in the database. It 
includes the enrollment, maintenance 
activities, providing status, and issuing 
material. 

This functional area represents the business 
processes required to run a successful 
Student Services Department. It includes 
the entire cycle of servicing a student from 
enrollment in a Course or Program until 
completion certification. It also includes the 
processes to service customers obtaining 
other MCI Products such as Job Aids, 
Course/Program components and materials, 
and Unit MCI Materials without enrolling in 
a Course or Program. 
This activity represents the process of 
ensuring the student meets the requirements 
necessary to effect the requested 
administrative action for the specified 

_| Course or Program. _ 





STUDENT SERVICING 

























VALIDATE ADMIN ACTION 
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Activity Name Activity Definition 


VALIDATE ENROLLMENT This activity represents the processes 
REQUIREMENTS validating the requestor's eligibility with the 
pre-requisites of the Course or Program the 
requestor intends to enroll. 
This activity represents the processes 
required to validate the requestor's 
eligibility to be issued requested materials. 
This activity verifies there is sufficient 
information available on student's request to 
begin research of transcript information. 
Information verified includes: Name, SSN, 
Address, and Dates of Service, 
This activity represents the processes of 
reconciling student activity records based 
on input from unit Training NCOs and 
updating MCI records with the consolidated 
input. 

























VALIDATE MATERIAL 
REQUIREMENTS 














VERIFY REQUESTOR INFORMATION 


















WORK RETURNED UARs 







Table C-3. Activity Dictionary. 


226 


Arrow Definition 


Activity Transactions/T2 This action calls the process for Customer Activity 
Transactions. 

Calls activity to process requests for administrative action. 

Admin Credit Transaction Transaction occurrence triggers an update to the Student's 

record giving administrative credit for Course on system 

date. 

Transient information collected from student and input by 

eleine. 

This is the requester's information that requests the 

administrative credit and 1s entered in at the PC. 

Requester meets requirements for intended administrative 

action. 

Archived Student and Course | Student Master File containing history of all students 

Data enrolled in MCI courses during the period Jan 1979 - Jan 
1989. History includes: Course Number; SSN; Last 
Name; Initials; Rank; MOS; RUC; Enrollment date; Re- 
enrollment date; Completion date; Extension (Y/N); Last 
Transaction code/date; Exams - Date/form/score for 
primary and alternate if applicable; Parent Group 
Type/Number. 

Automated Equipment All mechanical equipment maintained in SSD to provide 
support to SSD Operations: PC, Microfiche reader, 
Scantron, printer, PBX Telephone, etc. 

AVRS This represents the Conversant Automated Voice 
Response System (AVRS) which interacts with the 
database to provide a student's course status. 


| electronic correspondence. 
information. 


Comected DP-37s DP-37s that had information that failed to scan properly 
or that contained data that did not pass the editing and 
were corrected. 

Course Completion Data This is the information necessary to register course 
completion in the database and initiate generation of 
course completion certificates. 

Course or Program requirements that determine the 

requester's eligibility to enroll/disenroll/admin credit into 

the course or 


Course/Program Status Inquiry from a requester for status on a course or 
Request pro gram. 
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Admin Requests 






Approved 









Course Program 


Requirements 





Arrow Name Arrow Definition 


Customer Input Customer contact with MCI in any media form: Phone, e- 
mail (includes DMS and DISN), written correspondence 
by U.S. Mail (or similar), or by walk-in. Customer input 
can be by the customer or by the unit representative 
calling on behalf of the student or by returning Unit 
Activity Reports. 
General bundle category of inquiries or other requests 
from a Customer: status, information, transcript request, 
request for material, etc. 
Physical representation of a Diploma and a form letter of 
congratulation issued after completing all the courses in a 


eTam. 
envelope addressed for distribution. 
administrative action. 
date of Students record. 
that 1s distributed to the customer. 





















Customer Requests 








Diploma and Letter 









DP-37s A bubble sheet exam form that contains student and 
course information as well as the student's answers to the 
_| examination. | | 
Eligible | Requestor passes restriction for receiving requested 


materials. 


Enroll/T2.1 Calls activity to process enrollment. 


enroll a student. 
This is information provided by the requester that will be 
keyed in to initiate an enrollment transaction. 


Enrollment Transaction This represents a validated enrollment creating the flags 


necessary to generate shipping documentation when 
called. 
Erroneous DP-37s DP-37 information on the error listing. 


Error Codes Represents the information in the error code table. 


File, created from DP-37 data that do not pass editing, is 
the basis of OpScan error report. 

This arrow represents the information contained in an 
answer key. 

Evaluation of hand-graded exam provides a score for the 
exam to be entered into the system. 
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Arrow Name Arrow Definition 


The data that represents a student's failing score for a 









Failed Exam Data 

hand-graded exam, a PME exam, or an exam score that 
was obtained from the grading program with applicable 
information. 

Gen DP-37 File Data obtained from Student's exam (Gen DP-37) 
formatted into a file for editing and input into the Grading 
Program. 

Gen TOBESCAN File File, created from formatted data obtained from Student's 
exam (Gen DP-37) that passed editing, is the basis of the 
student's exam input file for the Grading Program. 

Generic DP-37s This 1s the exam form (DP-37) that has not been pre- 
formatted with any student, course and exam 
identification information but completed with the student's 
answers to the exam. 

Goodscan File Bundled Arrow: a File, created from formatted data 
obtained from Student's exam (Gen DP-37 and Pre- 
Slugged) that passed editing, is the student's exam input 
file for the Grading Program. 

MCIAIS data used to evaluate the student's exam in the 
Grading Program. 
oraded and scores entered into MCIAIS. 

Requester does not pass restriction for receiving | 
requested materials. ; 

Info Change Requests This is any request to change personal information on a 
student. Could be name, rank, SSN, address, component, 

Information Changes This 1s any request to change information on a student. 
Could be an enrollment, disenrollment, or other admin 






action to change personal information or PME credit. 
Invalid Enrollment | Enrollment request did not satisfy the requirement for 
Data necessary to build an invoice for mailing course or 
program components, courses or program materials, Job 
Aids or Training NCO materials. 
Transcripts 
Source data that is input form hand grading exams. 
Mechanism: Indicates where labor and manual processes 
occur. 


' enrollment. 
Table C-4. Arrow Dictionary. eo 


Arrow Definition 





Material Data Data necessary to distinguish material that 1s issued as an 
MCI product. Job Aids, Exams, Course/Program 
components, and Unit Training NCO Material. 


Material Requests 





Transient data that represents the MCI product material 
requested: Job Aids, Exams, Course/Program 

components, and Unit Training NCO Material. 
Customer requests for material. Could be components of 
a course, program or job aid; complete (re-issue) job aid, 
course or program; or re-issue of completion certificate or 
diploma. 












Material Shipment Data Data conceming material shipments. 
Material Status Request Customer's request for status on material shipment. 


Information about the course, programs and Job aids 


MCI Information 
distributed by MCI. This covers the Course Catalog and 
MCI Procedures Manual (eventually). 

MCTI's Procedures Manual which provides guidance, to 
student's and Training NCOs on the mission, functions, 
processes and protocols of conducting business with 
MCI. 


Standard operating procedures. 

Microfiche reader used to research Student and Course 
Information archived for period Jan 1979 - Jan 1989. 
make student data current. 

| make student data current. 

| __| make student data current. 


New Rank Updated information, from customer or source, usedto__ | 
make student data current. 

New Service Status Updated information, from customer or source, used to 

make student data current. 

Formatted data consisting of data from: failed exams, 

exams that did not pass editing, control numbers for 

identification, and error codes or descriptors to indicate 

reason for failure. 





MCI Procedures Manual 











OPSCAN Error List 







OPSCAN 7 optical mark reader. 


OSD/PMED Feedback Evaluations of courses and programs often returned with 


exam sheets following a student's completion of an 
examination. 
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Arrow Name Arrow Definition 


Passing Exam Data 





The data that represents a student's passing score for a 
hand-graded exam, a PME exam, or an exam score that 
was obtained from the grading program with applicable 
information. 
PBX Phone System AT&T Merlin telephone/voice-mail system used to 
answer phone calls to the 1-800-MCI-US MC telephone 
number. 


Personal E-Mail Electronic mail intended to be addressed to an individual 
employee or division of MCI. 
PME Essay Evaluation Evaluation of hand-graded PME essay exam. 


PME Essays 


Postal Delivery Mechanism: represents the method of delivery of input to 
SoD | 


Pre-Slugged DP-37s This is the exam form (DP-37) that has been pre- 
formatted with student, course and exam identification 










information and completed with the student's answers to 
the exam. 


Exams/T3.2 
Request/T2.5 


Process Status Request/T2.2 | Call: Calls activity to process status requests. | 





This is the information necessary to register program 
completion in the database and initiate generation of 
course completion certificates. a: =. 
Data obtained from Student's (Pre-Slugged DP-37) exam 
formatted into a file for input into the Grading Program. 
PS TOBESCAN File File, created from formatted data obtained from Student's 
exam (Pre-Slugged DP-37) that passed editing, is the 
basis of the student's exam input file for the Grading 
Pro 
MCIAIS data required to execute registrar processes: 
create, research and issue transcripts, create and issue 


diplomas, and accompanied form letter. 
were not successfully scanned. 

This represents the Generic DP-37s that were not 
successfully scanned. 

This represents the Pre-Slugged DP-37s that were not 
successfully scanned. 
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Program Completion Data 














EorpP237 File 























Arrow Name ; Arrow Definition 


Reply to Customer A reply to the customer is 1n response to a request and 
usually will be replied to in the same media the request 
was submitted: enrollment not accepted, course status, 
rejected admin action request, not qualified to receive 


requested materials. There are instances when the reply 
may be implied, 1.e. issuing a diploma in response to an 
exam or issuing material following enrollment are 
categories not represented by this arrow. 

Returned UARs Unit Activity Reports returned by a supported unit that 





has been reviewed and annotated with Training NCO 
feedback on student status and information. 


This represents the DP-37s that can be scanned based on 
physical condition. 
physical condition. 
were successfully scanned. 

This represents the Generic DP-37s that were successfully 
scanned. 

This represents the Pre-Slugged DP-37s that were 
successfully scanned. 





SSN Change Updated information, from customer or source, used to 
make student data current. 

MCIAIS data required to provide status. 
The customer's request for status. Status can be provided 
on a student's course, program, material shipment, 
transcript. 


Status Request on Comp The customer's request for status on a transcript 
Transcript 










Status Data 


Status Request 






customers. This includes name, rank, SSN, and address. 
| Status compiled by Marine Unit (RUC). 


This arrow provides the activity with student and address 


| Student and Address Data 
| data necessary to mail the diploma to the student 
completing the ram. 


Student and Course Data The existin » Student and Course Data on the database 


includes name, grade, service component, and SSN. 
Student's Course and The existing Student, Course and Program Data on a 
Program Data specific instance. 


Student's Program Data Program information for student's in the database. 
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Arrow Name Arrow Definition 


Data 
produce in response to a transcript request. 


Course completion history of student with accreditation 
data. 

Transcript Package This is the transcript and the accompanying form letter 
produced in response to a transcript request and packaged 


for mailing. 

System date provided when transcript is completed to 
update MCIAIS for future status requests. 

Customer's request for a transcript or SSD clerk's input 
for same. 


Transcript Request This is the Transcript Customer's information required to 
Information research and produce a transcript: Name, SSN, Address, 
Dates of Service. 


Customer's request for status in response to a transcript 
request or S SD clerk's input for same. 
record reconciliation. 


UAR Request Customer's request for a Unit Activity Report or SSD 
clerk's input for same. Request can be for a single UAR or 









Transcript Course History 










Uncorrectable DP-37s DP-37s that could not be corrected due to lack of 
available information provided on the bubble sheet 
submitted. 


This represents the DP-37s that can not be scanned based 
on physical condition or OpScanner rejection. 

This represents the DP-37s that can not be scanned based 
on physical condition or OpScanner rejection. 








Updated Student Info Student information updated by phone call, walk-in, e- 
mail, UAR, or U.S. mail. This can be the result of any of 
the student activity transactions include an enrollment, 
disenrollment, student's information that 1s changed like 
name, rank, service, component, status, etc., or course 
completion, but is directed at updating personal 
information which should be verified prior to executing 


the transaction. 


Valid Enrollment Transient Enrollment data that passed evaluation against 
course/program requirements. 
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Arrow Definition 


Work Returned UARs/T1.2.2 | Call: Calls activity to process student activity servicing to 
update student records based on input provided with 
returned UAR. 
A Unit Activity Report that has been reconciled by the 
using unit and UAR processing clerk has updated the 
student records based on the reconciliation. To File. 














Worked UAR 
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Figure C-1. To Be Process Model Node Tree Diagram (TO). 
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Figure C-2. To-Be Process Model Context Diagram (T-0). 
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Figure C-3. To-Be Process Model IDEFO Diagram (T0). 
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Figure C-4. To-Be Process Model IDEFO Diagram (T1). 
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Figure C-S. To-Be Process Model IDEFO Diagram (T1.1). 
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Figure C-6. To-Be Process Model IDEFO Diagram (T1.1.3). 
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Figure C-7. To-Be Process Model IDEFO Diagram Geers 1): 
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Figure C-8. To-Be Process Model IDEFO Diagram (T1. 1.4). 
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Figure C-9. To-Be Process Model IDEFO Diagram (T1.2). 
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Figure C-11. To-Be Process Model IDEFO Diagram (T2.1). 
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Figure C-12. To-Be Process Model IDEFO Diagram 24,2). 
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Figure C-13. To-Be Process Model IDEFO Diagram (T2.2). 
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Figure C-14. To-Be Process Model IDEFO Diagram (T2.2.1). 
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Figure C-15. To-Be Process Model IDEFO Diagram (T2.2.2). 
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Figure C-16. To-Be Process Model IDEFO Diagram (T2.2.3). 
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Figure C-17. To-Be Process Model IDEFO Diagram (12.3). 
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Figure C-18. To-Be Process Model IDEFO Diagram (T2.4). 
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Figure C-19. To-Be Process Model IDEFO Diagram (T2.4.2). 
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Figure C-20. To-Be Process Model IDEFO Diagram (T2.5). 
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Figure C-22. To-Be Process Model IDEFO Diagram (T3). 
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Figure C-23. To-Be Process Model IDEFO Diagram (T3.1). 
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Figure C-24. To-Be Process Model IDEFO Diagram (T3.1.1). 
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Figure C-25. To-Be Process Model IDEFO Diagram (T3.1.2). 
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Figure C-26. To-Be Process Model IDEFO Diagram (T3.2). 
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Figure C-27. To-Be Process Model IDEFO Diagram (T3.3). 
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Figure C-28. To-Be Process Model IDEFO Diagram (T3.3.1). 
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Figure C-29. To-Be Process Model IDEFO Diagram (T3.3.2). 
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Figure C-30. To-Be Process Model IDEFO Diagram (T3.4). 
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Figure C-31. To-Be Process Model IDEFO Diagram (T4). 
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Figure C-33. To-Be Process Model IDEFO Diagram (T4.2). 
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Figure C-34. To-Be Process Model IDEFO Diagram (T4.2. 1). 
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Figure C-35. To-Be Process Model IDEFO Diagram (T4.2.2). 
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Figure C-36. To-Be Process Model IDEFO Diagram (T4.2.2.1). 
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Figure C-37. To-Be Process Model IDEFO Diagram (T4.2.2.2). 
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